Author |
Message
|
xstuvw |
Posted: Thu Jan 26, 2012 9:31 am Post subject: Repeatedly Sending Messages |
|
|
Novice
Joined: 29 Nov 2011 Posts: 21
|
I have the following problem (please yell at me if this is an incorrect use of MB):
The business logic is:
- Send a message to an application.
- If a response occurs, continue the message onwards.
- Otherwise, if a response does not occur - resend the message to the application 'n' times over 'm' minutes, then discard.
My idea is to:
- take a message in
- store a copy of it in a copy queue
- if there IS a response, eat the message out of the copy queue (using a GET) and continue
- if there ISN'T a response, continue to attempt to send the message from the copy queue
Is there a way, using Timer nodes (or some other method), to repeatedly try to send all of the messages in a queue every 'm' minutes for 'n' tries? Or even just every 'm' minutes?
EDIT:
Effectively this: http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r1m0/index.jsp?topic=%2Fcom.ibm.etools.mft.doc%2Fac20806_.htm
but to stop the process if a response is returned. |
|
Back to top |
|
 |
mqjeff |
Posted: Thu Jan 26, 2012 9:38 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
I would send the message with an expiry value == the time you need to wait for a response.
Then set the report options to generate the full message when a given message expires.
Then process the report message and resend the message with a new expiry value. |
|
Back to top |
|
 |
xstuvw |
Posted: Thu Jan 26, 2012 9:44 am Post subject: |
|
|
Novice
Joined: 29 Nov 2011 Posts: 21
|
I might be misunderstanding. Are you suggesting that we send a message to the application, and another copy of that message (with the expiry set), to the "reprocess" queue. Then when the message in the reprocess queue expires I resend?
That makes sense - just verifying. Also, when you say report options is that a setting on the MQInput or on the MQMD? |
|
Back to top |
|
 |
Vitor |
Posted: Thu Jan 26, 2012 9:51 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
xstuvw wrote: |
I might be misunderstanding. Are you suggesting that we send a message to the application, and another copy of that message (with the expiry set), to the "reprocess" queue. Then when the message in the reprocess queue expires I resend? |
Send a single copy of the message to the application. When you get the report message back because it expired without being read, resend it to the consuming application.
xstuvw wrote: |
Also, when you say report options is that a setting on the MQInput or on the MQMD? |
MQMD via the put (MQOutput). _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
xstuvw |
Posted: Thu Jan 26, 2012 9:54 am Post subject: |
|
|
Novice
Joined: 29 Nov 2011 Posts: 21
|
The message will always be read in the application queue, though. So, in theory, the message will never have a chance to expire (unless it is sent to another queue as well). |
|
Back to top |
|
 |
xstuvw |
Posted: Thu Jan 26, 2012 10:42 am Post subject: |
|
|
Novice
Joined: 29 Nov 2011 Posts: 21
|
I understand the solution - but I'm a bit confused about how MQMD.Report works. I've read through the documentation but it's a bit sparse.
This is what I am doing (as well as setting expiry):
Code: |
SET OutputRoot.MQMD.Report = MQRO_EXPIRATION_WITH_FULL_DATA |
Upon expiry do I catch this in my initial MQInput?
How do I determine the difference between this message and an actual error? |
|
Back to top |
|
 |
adubya |
Posted: Thu Jan 26, 2012 11:01 am Post subject: |
|
|
Partisan
Joined: 25 Aug 2011 Posts: 377 Location: GU12, UK
|
How about using a flow with a Collector node which is configured with two inputs, one input is the message you've sent to the app and the other is the response from the app. Configure the Collector to correlate using whatever ties the request to the response.
Set a expiry value on the Collector such that is you don't get a response from your app then the Collector will timeout and send the received output (your original request msg) to the Expire terminal. Wire this terminal to a compute node which increments a counter in either an element you bolt on to the msg or somewhere in a MQ header. If the counter is less than your max retry limit then send the msg back to your initial flow to resend to the app.
If you do get a response from the app then your Collector will correlate and pass the req/resp pair through to whatever you wire to the "out" terminal.
Hope this makes sense ?
Disclaimer: The above written without ever having used a Collector node  |
|
Back to top |
|
 |
xstuvw |
Posted: Thu Jan 26, 2012 11:20 am Post subject: |
|
|
Novice
Joined: 29 Nov 2011 Posts: 21
|
That's another good idea but I think it's more work than just shooting a report as soon as a message has timed out. I'm just a little unclear of the usage of MQMD.Report, though. |
|
Back to top |
|
 |
adubya |
Posted: Thu Jan 26, 2012 11:28 am Post subject: |
|
|
Partisan
Joined: 25 Aug 2011 Posts: 377 Location: GU12, UK
|
xstuvw wrote: |
That's another good idea but I think it's more work than just shooting a report as soon as a message has timed out. I'm just a little unclear of the usage of MQMD.Report, though. |
I don't think the timeout approach suggested above is suitable for you as you'll only get the report if the message times out while still on the queue i.e. the app hasn't read it. You mentioned that the app will consume all messages but it's the reply which may or may not come back.
With the Collector approach you don't actually have to write much code, WMB is doing all the hard stuff  |
|
Back to top |
|
 |
Vitor |
Posted: Thu Jan 26, 2012 11:38 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
xstuvw wrote: |
Upon expiry do I catch this in my initial MQInput? |
No, with an MQInput node attached to your ReplyToQ
xstuvw wrote: |
How do I determine the difference between this message and an actual error? |
Inside WMB the MQMD.SourceQueue will be different. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
xstuvw |
Posted: Thu Jan 26, 2012 11:38 am Post subject: |
|
|
Novice
Joined: 29 Nov 2011 Posts: 21
|
But if you place the message on two queues: app_in, and reprocess_in; and only set the expiry on reprocess_in; it will work. |
|
Back to top |
|
 |
xstuvw |
Posted: Thu Jan 26, 2012 11:53 am Post subject: |
|
|
Novice
Joined: 29 Nov 2011 Posts: 21
|
Thanks, Vitor, I understand completely.  |
|
Back to top |
|
 |
xstuvw |
Posted: Thu Jan 26, 2012 1:36 pm Post subject: |
|
|
Novice
Joined: 29 Nov 2011 Posts: 21
|
mqjeff wrote: |
I would send the message with an expiry value == the time you need to wait for a response.
Then set the report options to generate the full message when a given message expires.
Then process the report message and resend the message with a new expiry value. |
I have run into a problem. This solution doesn't work if I only send in one message because expired messages are only "scrapped" on another queue BROWSE/GET. |
|
Back to top |
|
 |
|