| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQSeries Client - MQCMIT / MQBACK program logic query. |
« View previous topic :: View next topic » |
| Author |
Message
|
| jconway |
 Posted: Thu Jun 19, 2003 4:13 am Post subject: MQSeries Client - MQCMIT / MQBACK program logic query. |
 |
|
Novice
Joined: 28 Apr 2003
Posts: 17
Location: Paris, France
|
Hello,
I'm wondering if someone can advise me on how to solve the following dilemna.
My application running as an MQSeries Client has the following (very) basic program logic :-
MQCONN to queue manager
MQOPEN queue for output
MQGET msg under SYNCHPOINT
Process the message
If process successful
MQCMIT
Else
MQBACK with the future desire to MQGET this message again and
try to process it again.
Loop to MQGET to get next message on the Queue
Note - if the connection is lost then the client tries to reconnect.
Now, here's my dilemna.
If I lose the connection to the Queue Manager after processing the message but before the MQCMIT or the MQBACK is done, then, when the proxy code in the Queue Manager (that issues the MQI verbs on the Client's behalf) realises that the connection to the Client is lost, he will back out the message and the message will become visible again on the queue with the backout counter incremented.
So far so good.
After the Client reconnects, the MQGET will find this message but I have no way of telling whether this was a message I had originally intended to MQCMIT (ie. Remove permanently from the queue and NOT process it again) or to MQBACK (ie. I DO want to process it again).
I'm sure there's an obvious way around this that I'm missing or that my basic understanding of the above processing is flawed, I'm new to MQ. I would really appreciate any suggestions as to how to solve this issue.
Thanks, Jim. |
|
| Back to top |
|
 |
| mqonnet |
| Posted: Thu Jun 19, 2003 6:29 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
After you have successfully got the message under syncpoint, if the connection fails or for some reason MQ had to backout the message, then there is no way for MQ to intimate the application of the same, but one.
And which is, through MQCMIT call. Since your get passed successfully, your app would go through the commit logic and would try and issue MQCMIT. When it does so, it would get a reason code MQRC_BACKED_OUT which you need to handle appropriately in your code. When you do so, you can as well store the msgid/correld and any other distinguishing attributes of your message. So that when you do a get next time, and co-incidently get the same message again, you know that this is the one that you were trying to process or rather processed(since i dont know what "process the message" does in your app).
Hope this helps.
Cheers
Kumar |
|
| Back to top |
|
|
| jconway |
| Posted: Thu Jun 19, 2003 7:15 am Post subject: |
|
|
Novice
Joined: 28 Apr 2003
Posts: 17
Location: Paris, France
|
Thanks a million for your reply. I still have a couple of questions.
1. If I do an MQGET of a message then the connection between my MQ Client and the Queue Manager is lost and THEN I try to do an MQCMIT won't I get a MQRC_CONNECTION_BROKEN reason code from the MQCMIT?
(Also, apparently with Clients, there is a possibility that the commit may have actually worked even if this reason code is received .. bizare!).
2. Am I correct in thinking that when an MQBACK is performed the message becomes visible once more on the queue but it's position on the queue remains unaltered (ie. it's the first on the queue, I do a get with SYNCHPOINT, a second message arrives on the queue, then if I do an MQBACK it becomes visible as the first message on the queue again BEFORE the second message that arrived)?
Thanks for the "store the MsgId" idea. That's definitely the way I'll go.
Really appreciate the help.
Jim. |
|
| Back to top |
|
|
| zpat |
| Posted: Thu Jun 19, 2003 7:25 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
One other tip - you can inspect the "backout count" in the message header to see how many times it had already been read and backed out.
If this value is above "n", you might want to abandon the attempt to process it to avoid a loop. Alternatively set a "backout requeue queue" on the queue definition with a threshold "n", so that the queue manager will automatically send it to this other queue when it has been backed out "n" times on the original queue.
I recommend using a backout queue in the definitions as a safeguard because your code might even fail before you can read the backout value in the message (it's happened to me!) and loop indefinitely.
Using XA coordination can ensure a consistent state between a queue and a database.
Last edited by zpat on Thu Jun 19, 2003 8:14 am; edited 1 time in total |
|
| Back to top |
|
|
| mqonnet |
| Posted: Thu Jun 19, 2003 7:34 am Post subject: |
|
|
Grand Master
Joined: 18 Feb 2002
Posts: 1114
Location: Boston, Ma, Usa.
|
Backoutcount suggested by zpat is also a good way to go.
Yeah, with clients you have the drawback of having inconsistency in the event of a "pull the plug" scenario or a similar one. And hence you have to code your application to handle such instances.
As for the return code, i guess you would get connection_broken.
Cheers
Kumar |
|
| Back to top |
|
|
| bower5932 |
| Posted: Thu Jun 19, 2003 8:03 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
