Hi,

My requirement is I should read the message from MQ Queues through MQ adapter and process them.But the message should not be deleted from the MQ Queue untill my transaction gets completed.In that way even if Integration server goes down while processing a message there will be no loss of messages.

–>Using a Get service I am able to control the transaction and if I roll back, the message is not deleted from the MQ Queue.

–>But using Listener and Listener Notification, transactions are completely managed by the server itself. The documentation says if there is an exception thrown in the Notification it rollbacks the message. Actually what’s happening is if an exception is thrown its putting the message into the Dead Letter Queue.

So what I am assuming is if we are using transactions and Get service, MQ Adapter just copies the message from MQ Queue and when we commit it deletes the message from queue. If we rollback it just does not do anything. (So the message is left in the Queue as it is only copied but not read).

But if we are using Listener – Listener notification, the listener is reading the message from Queue (Not copying. Once we read the message from MQ Queue its not available in queue anymore) and if some exception is thrown while rolling back it’s putting back the message into Dead Letter Queue.

Though documentation says that the message is not deleted from the MQ Queue until it is processed successfully by the Listener Notification it is not working in that way.

Any ideas/suggestion/corrections for my problem/assumptions.

Thanks a Lot in advance.
Kiran

Kiran,

Even with the Listener/Notification combination, the message can be successfully rolled back to the queue in the event of an exception. Check the Backout Threshold property of your listener… I guess it has a value ‘1’ (default), increase this number to a higher value and then try. Also, in your message processor service, use Exit Flow [Signal failure] as the last step in the event of failure (ie the scenario in which you want the message to be rolled back to the queue).

The Backout Threshold property determines the number of times a read is to be attempted on a message before it is moved the the DLQ… since the default value of this property is 1, after your first read, when the processing service fails, the message is moved to the DLQ.

Hope this helps, Rohit

Rohit,

I tried increasing the BackOut Threshold property of the lisetner.And what’s happening is if the Backout Threshold value is 10, after trying 10 times it is putting it into the Dead Letter Queue.But during the processing of the message these 10 times i cannot see the message in the Queue.

What i tried is increased the Threshold value to 200 and while the listener is processing the message i monitored the MQ Queue.I expected the message to be there in the Queue untill the processing for 200 times is completed ,but its not there. And also i tried shutting down the server while the processing for 200 times is going on and the message is lost.It is not there in the MQ Queue and it is also not there in the Dead Letter Queue.

And my problem is this,we are loosing messages in Real time because of this behaviour. .

I am seeing for some type of behaviour like the message should not be deleted fromt the Queue till the processing is successfull(or till the threshold value is reached) ,in that way even if the server goes down the messages are left in the Queue(or dead letter queue but not lost).

Thanks a Lot for your suggestion, it helped me to get a better understaning of the adapters behaviour.

-Kiran

Kiran,

Looks like you are using a Synchronous Notification… use an Asynchronous Notification instead. An Asynchronous Listener Notification publishes a document (with MQ Message) to the Broker which is persisted. So even if your IS goes down, the message will not be lost.
In case you don’t have the Broker (highly recommended to have and use it though), the Async Listener Notification will publish the document locally to IS, which will be persisted in the IS Document Store.

Also, unless it was just for testing you wouldn’t want to pump up the Backout Threshold to a double figure number.

HTH, Rohit

Rohit,

You are right ,i am using the Synchronous notification till now.As per your suggestion i started using Asynchronous Notification. For the asynchronous notification i wrote a trigger and in the trigger i am calling a flow service.

And in the service as my last step i am using an exit flow (signal failure).
What ever is the threshold value i cant see the message on the MQ Queue or in the Dead Letter Queue.

In the logs i can see this
2006-03-16 17:43:15 EST [ISS.0098.0049C] Exception:com.wm.lang.flow.FlowException: while executing trigger. Rejecting Document for TriggerStore:TestMQ:MQListenerNotificationTrigger.

We are not using the Broker and as the broker should be purchased i think we cannot use this as of now.

And i can see some documents in the folder “IntegrationServer/Document Store” with names “TriggerStoredata0000000” and “TriggerStorelog0000000”.But i cant see any messages.

Totally confused .Am i missing some thing in the configurations.

Thank you so much for helping me.

-Kiran

Exiting the flow with signal failure is not going to roll back the mq message. The act of publishing the mq message to the broker or IS server via the notification is considered a successful transaction, once the message is persisted the broker or IS server acks back to the adapter which removes the message. The message is removed at that point from the MQ queue not when you flow service runs successful or not.

A couple of pointers. 1- If your flow service has auditing turned on for error only with save pipeline then you can resubmit the transaction. No need to go back to MQ. 2 -If your IS server fails while processing the transaction in the flow service, it will be reprocessed once the server comes back up assuming you setup the trigger correctly 3 - If you want the flow service to resubmit a failed transaction automatically in the event of a transient failure within the flow service then you need to throw a runtime exception, not a service execption which exit flow signal failure is a service exception. There are some other threads here which explain how to do that.

I am also using synchronous transaction listener and facing similar issues. I dont want messages to move to dead letter queue and want the message to stay in original queue.

I will highly appreciate any help on this.

Regards,
Kapil

Hi Rohit/Mark G,

I am trying to configure MQAdapter connection and have a question regarding the CCSID value to enter…I know the default value is 819 per the docs…So currently i have set for listen/get related connections CCSID as CP819 and for put CCSID as 819 (with out CP)…Is this OK to setup??

I already asked my MQ folks what should be the value to consider other than default 819 and they suggested 500…

Can you add your valuable suggestions on this…

TIA,
RMG

Hi, i’m facing with a similar issue… someone know any fix on this?