| Author |
Message
|
| pcrparimi |
 Posted: Fri Jul 18, 2003 10:04 am Post subject: Triggering Issue |
 |
|
Apprentice
Joined: 09 Oct 2001
Posts: 43
Location: NY
|
Hi,
we are triggering a process which picks the message from the same queue on which triggering is configured. The process gets the message under syncpoint and if some thing goes wrong rolls back and then the process exits/abends.
But the problem was, transaction is getting triggered again for the same message after rollback.
Seems whenever we rollback, queue manger is considering it as a new put and putting a new trigger message in Initiation queue.
Is it a common behavior or am i missing some thing.
any ideas to not to trigger the process for same message.
Queue is configured to trigger for First message.
Thanks,
Parimi |
|
| Back to top |
|
 |
| GMcCarthy |
| Posted: Fri Jul 18, 2003 10:32 am Post subject: |
|
|
Centurion
Joined: 06 Nov 2001
Posts: 113
Location: Melville NY
|
Messages that are backed out
When processing messages from a queue under the control of a unit of work, the unit of work could consist of one or more messages. If a backout occurs, the messages which were retrieved from the queue are reinstated on the queue, and they can be processed again in another unit of work. If the processing of a particular message is causing the problem, the unit of work is backed out again. This could cause a processing loop. Messages which were put to a queue are removed from the queue.
An application can detect messages that are caught up in such a loop by testing the BackoutCount field of MQMD. The application can either correct the situation, or issue a warning to an operator.
In WebSphere MQ for z/OS, to ensure that the back-out count survives restarts of the queue manager, set the HardenGetBackout attribute to MQQA_BACKOUT_HARDENED; otherwise, if the queue manager has to restart, it does not maintain an accurate back-out count for each message. Setting the attribute this way adds the penalty of extra processing.
In WebSphere MQ for iSeries, MQSeries for OS/2 Warp, WebSphere MQ for Windows, MQSeries for Compaq OpenVMS Alpha, and WebSphere MQ on UNIX systems, the back-out count always survives restarts of the queue manager. Any change to the HardenGetBackout attribute is ignored.
_________________
Regards,
Gina
IBM Certified MQSeries Specialist |
|
| Back to top |
|
|
| pcrparimi |
| Posted: Fri Jul 18, 2003 10:48 am Post subject: |
|
|
Apprentice
Joined: 09 Oct 2001
Posts: 43
Location: NY
|
Gina,
Thanks for your quick reply. My question is whenever i backout, will it be considered as a new PUT.
For triggering to happen QM has to put a message in initiation queue.
Regards,
Poorna. |
|
| Back to top |
|
|
| GMcCarthy |
| Posted: Fri Jul 18, 2003 10:53 am Post subject: |
|
|
Centurion
Joined: 06 Nov 2001
Posts: 113
Location: Melville NY
|
And when you backout, It will put the message back on the queue which will generate another trigger message on your initiation queue. This is what is causing your looping.
"An application can detect messages that are caught up in such a loop by testing the BackoutCount field of MQMD. The application can either correct the situation, or issue a warning to an operator."
_________________
Regards,
Gina
IBM Certified MQSeries Specialist |
|
| Back to top |
|
|
| pcrparimi |
| Posted: Fri Jul 18, 2003 10:54 am Post subject: |
|
|
Apprentice
Joined: 09 Oct 2001
Posts: 43
Location: NY
|
I got it.
Thanks a lot, have a good week-end
Regards,
Poorna |
|
| Back to top |
|
|
| bbeardsley |
| Posted: Fri Jul 18, 2003 2:06 pm Post subject: |
|
|
Acolyte
Joined: 17 Dec 2001
Posts: 52
Location: Dallas, TX, USA
|
Poorna,
You can solve your problem by having your application turn triggering off after it connects to get the messages. If the process fails and the message has to be rolled back, triggering will be off. If the application is successfull, then it should turn triggering back on before it disconnects.
-Bridgette |
|
| Back to top |
|
|
| GMcCarthy |
| Posted: Fri Jul 18, 2003 3:31 pm Post subject: |
|
|
Centurion
Joined: 06 Nov 2001
Posts: 113
Location: Melville NY
|
What about applications that are expecting to get messages (triggered off) that are behind the message that was put back? Won't they wait until the 'backed out' message gets removed?
_________________
Regards,
Gina
IBM Certified MQSeries Specialist |
|
| Back to top |
|
|
| bduncan |
| Posted: Fri Jul 18, 2003 4:33 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Bridgette,
There are two downsides to your approach:
1) If your application dies before it can turn triggering back on, the messages will begin to pile up on the queue.
2) If your application rolls back a bad message and triggering stays off, the whole system comes to a halt until a human intervenes.
The most common approach I've seen to this problem is what Gina is describing. Your application should look at the backout count of any message it pulls off the queue (before attempting to process it). If it finds the backout count is very high (say 999), it is safe to assume that the message is what we call a "poison message", and it should be put to some other queue. That way, processing can continue and eventually a human can look at the poison message and figure out what is wrong with it.
Of course, sometimes you can't do this, because perhaps your messages MUST be processed in a certain order, in which case, you may have to resort to what Bridgette's solution.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| bbeardsley |
| Posted: Mon Jul 21, 2003 7:18 pm Post subject: |
|
|
Acolyte
Joined: 17 Dec 2001
Posts: 52
Location: Dallas, TX, USA
|
Gina,
As Brandon suggested, look at the backout count. A method to counteract the two downsides he points out would be to monitor the queue depth or trigger on/off status of the queue so you would be alerted when your application abends.
Bridgette Beardsley |
|
| Back to top |
|
|
| pcrparimi |
| Posted: Tue Aug 05, 2003 4:49 am Post subject: |
|
|
Apprentice
Joined: 09 Oct 2001
Posts: 43
Location: NY
|
Hi Gina,Bridgette, Brandon
I tried a slightly different approach for this problem.
I am opening the queue in MQOO_BROWSE + MQOO_INPUT_*.
First I get the message using MQGMO_BROWSE_FIRST.
Then process the browsed message and put it into another two Queues. If everything is fine, do a destructive get (MQGMO_MSG_UNDER_CURSOR). If I am not able to process the message or not able to put the message in any of my two queues, do a backout (by assuming put is success in one queue and failed in other queue).
But this still triggering the same process multiple times if I do a backout. Is it because opening of the queue using MQOO_INPUT_*.
Thank You for your suggestions.
Poorna. |
|
| Back to top |
|
|
|
|
