| Author |
Message
|
| tkvinodh |
 Posted: Tue May 06, 2003 3:31 am Post subject: Retrying messages due to business requirement |
 |
|
Newbie
Joined: 06 May 2003
Posts: 2
|
We have a typical requirement of reprocessing some messages when they fail due to some reason. For example there is an update message coming in a queue and getting processed even before the insert message for the same record has been processed from another queue. In this case we want to put the update message back onto the queue and reprocess later at a predefined period of time.
Need suggeston on how the above can be achieved.
Thanks. |
|
| Back to top |
|
 |
| JohnMN |
| Posted: Tue May 06, 2003 6:35 am Post subject: |
|
|
Novice
Joined: 26 Feb 2003
Posts: 19
|
The easiest way I can think of offhand is to do the MQGET under a UOW (unit of work). It's perfectly valid, even for a single message.
On the MQGET call, you would need to set MQGMO_SYNCPOINT. If the insert message had been received, and you want to keep the update message, issue MQCMIT. This will remove the message from the queue.
If you get the update before the insert, issue MQBACK. This will return the message to the queue so that you can get it at a later time.
John |
|
| Back to top |
|
|
| vmcgloin |
| Posted: Tue May 06, 2003 7:15 am Post subject: |
|
|
Knight
Joined: 04 Apr 2002
Posts: 560
Location: Scotland
|
The way we do this kind of thing is to put the message that cannot be processed to another queue with a different generic application that handles the retries, for all platforms & apps, given a retry interval and maximum retry count.
I do not know of any way other that the UOW already suggested to handle such behaviour directly by MQ. But I'd also be interested to hear if/how other people do this...
Cheers,
Vicky |
|
| Back to top |
|
|
| tkvinodh |
| Posted: Tue May 06, 2003 10:25 pm Post subject: |
|
|
Newbie
Joined: 06 May 2003
Posts: 2
|
Thanks for the response. We have thought of using MQ UOW, but when I rollback the record I think it goes to the bottom of the queue. As per our requirement we want retry the same message after every X minutes till it is successfully processed. What I thought of is to write the error records to another Queue so that the main application is not processing the error recod and also write the error message ID's to some table. Another generic application need to maintain the table and process the records from the error queue at recurring interval. yes the temporarily table can maintain the time stamp etc.
Thanks,
Vinny |
|
| Back to top |
|
|
| bduncan |
| Posted: Wed May 07, 2003 10:54 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
The other alternative is to put the message to another queue which is triggered, and has a trigger interval of 10 minutes.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| techno |
| Posted: Thu May 08, 2003 9:30 pm Post subject: |
|
|
Chevalier
Joined: 22 Jan 2003
Posts: 429
|
Can you try using message selector? By doing this, you can avoid using another queue. You need to use transactions also.
Say, you get a msg with update/insert, read corresponding insert/update using selector.
In case the first msg is for insert, insert the row.
In case the first msg is for update,
use selector to find insert msg.
if insert msg is found, do the appropriate operation.
in case the first msg is for update, if insert msg is not found, backout |
|
| Back to top |
|
|
| garfield |
| Posted: Sun May 18, 2003 11:15 pm Post subject: |
|
|
Newbie
Joined: 18 May 2003
Posts: 3
|
How do you trigger an applicaation after 10 mins. I guess the MQ supports trigger on number of messages. It does not support the triggering of application after the specified time interval, does it?
I guess, to acheive the same, we may have to write our own trigger monitor. Am i right?
Also one way of acheiving the same requirement as per asked, is to maintain the collection of the rejected messages and let the application decide when the specified time interval is expired.
Put the message onto the retry queue (a seperate queue) when the application decides to retry the message, let it do a selective pull, on basis of message id, from the retry queue and process the message.
regards |
|
| Back to top |
|
|
| bduncan |
| Posted: Mon May 19, 2003 10:12 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
No, MQSeries does not support triggering after a given time interval.
What it DOES support is a trigger interval, combined with a trigger type of first, depth, or every.
Imagine the following scenario:
I setup a trigger on "first"
The queue depth goes from 0 to 1, so the queue manager launches my application. These messages take a few seconds to process, and while my application is busy processing that message, several more messages arrive. Now my application is smart so after processing the first message, it keeps pulling messages off the queue and processing them.
Now one of two scenarios occurs:
1) My application simply can't keep up with the rate of incoming messages, and the queue depth keeps increasing
2) My application dies, but because the queue depth is already above 0, the depth can't go from 0 to 1 and cause the queue manager to retrigger my application
In either case, bad things are going to happen. That is, unless I have setup a trigger interval. Let's say I set it to 10 minutes. It means that if the queue depth hasn't gone down 10 minutes after the last trigger occured, the queue manager should retrigger the application.
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| garfield |
| Posted: Mon May 19, 2003 8:07 pm Post subject: |
|
|
Newbie
Joined: 18 May 2003
Posts: 3
|
I guess my requirement there is for processing every message after 10 minutes of it's arrival, is that right? That too the message should be processed within some sort of single multi threaded application, as various actors on different messages need to share some critical data (which i gues cannot be done using multi processing).
The only way i see is
1. to write my own trigger monitor
2. to set this logic in my appplication.
If this is true can someone help me, how to write my own trigger monitor?
Also i would like to know if MQ can act as a transaction manager for an resource manager (legacy application) implementing XA Interfaces? If this is possible how do i go about it? |
|
| Back to top |
|
|
| Jesh |
| Posted: Wed May 21, 2003 9:25 am Post subject: |
|
|
Novice
Joined: 09 Apr 2003
Posts: 12
|
If your platform is zOs, you might be interested in my suggestion to make use of MQ expiry for your scenario.
You should have a new queue, you can call it the "Pending Expiry" queue. Your application should put all the retry messages into this new queue with expiry time of X minutes , MQRO_EXPIRATION_WITH_FULL_DATA option set & ReplyToQ as your original appln queue. You should have this queue indexed by MsgID or CorrelID.
You should also have another program(I would call it the "Siphon" application). This should be a long running appln. that would just do a dummy MQGET with a nonexisting MsgID(if you had indexed your queue on MsgID) or a nonexisting CorrelID(if you had indexed your queue on CorrelID). All the expired messages would be transferred to your application queu after 10 minutes. |
|
| Back to top |
|
|
|
|
