| Author |
Message
|
| jamesyu |
 Posted: Tue Jun 02, 2009 9:43 am Post subject: Configure globally coordinated message flows? |
 |
|
Acolyte
Joined: 31 Jan 2007
Posts: 70
|
My message flow takes an input message from a local queue and writes an output message to a remote queue via the MQOutput node. This remote queue routes this message to a target queue on another queue manager. The local input queue has a Backout requeue queue defined.
The question is, if anything wrong happened to the target queue on another queue manager, such as the queue is full, or channels not running properly, etc.. Can the whole transaction be rolled back so the input message will be backed out on its backout queue?
What to take to make this happen?
Thanks,
James |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Jun 02, 2009 9:46 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If the message is successfully PUT to the XMITQ, then there is nothing that can be done to rollback the input message at some later date.
If the message can't be PUT to the XMITQ, the MQOutput node will throw an Exception. |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Jun 02, 2009 9:59 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
It would go to the DLQ on the target QM if needed.
If you really wanted to avoid the possibility of not arriving on the target queue, then use a local queue and have the application connect to the WMB QM with a client connection.
However 1000s of sites don't worry about this - just set up alerting on DLQs. |
|
| Back to top |
|
|
| jamesyu |
| Posted: Tue Jun 02, 2009 10:22 am Post subject: |
|
|
Acolyte
Joined: 31 Jan 2007
Posts: 70
|
| zpat wrote: |
It would go to the DLQ on the target QM if needed.
If you really wanted to avoid the possibility of not arriving on the target queue, then use a local queue and have the application connect to the WMB QM with a client connection.
However 1000s of sites don't worry about this - just set up alerting on DLQs. |
What's happening now is, the messages are landed on the DLQ on another queue manager, for example, the target queue doesn't exist or is full, etc.. But for some specific business reason, we don't want to see those messages on DLQ. Instead, we want those messages to be rolled back to its own backout queue. Sounds like this cannot be done. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Jun 02, 2009 3:42 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| jamesyu wrote: |
What's happening now is, the messages are landed on the DLQ on another queue manager, for example, the target queue doesn't exist or is full, etc.. But for some specific business reason, we don't want to see those messages on DLQ. Instead, we want those messages to be rolled back to its own backout queue. Sounds like this cannot be done. |
You cannot rollback a message that was never consumed (queue full) to a backout queue. That's why the channel agent puts them on the DLQ.
In order to roll back a message to the backout queue you have to consume it first.
If you have trouble with queue full you need to scale your message consumer application to get more throughput. Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue Jun 02, 2009 4:02 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
| jamesyu wrote: |
| What's happening now is, the messages are landed on the DLQ on another queue manager, for example, the target queue doesn't exist or is full, etc.. But for some specific business reason, we don't want to see those messages on DLQ. Instead, we want those messages to be rolled back to its own backout queue. Sounds like this cannot be done. |
The transfer of messages to another queue manager is done under a separate UOW (by the Message Channel Agents) so it is not possible to back this out in the original app UOW that put the messages to the qremote / xmitq.
_________________
Glenn |
|
| Back to top |
|
|
| aditya.aggarwal |
| Posted: Wed Jun 03, 2009 1:44 am Post subject: |
|
|
Master
Joined: 13 Jan 2009
Posts: 252
|
We have faced a similar problem very recently in our environment with very similar Architecture. Target queue was full so the messages start pilling up in to the xmit queue at Broker.
This have created problem in message flow and it starts throwing exception.
After analysis we found that the UOW of the message arrival to Xmit queue at Broker and the UOW of sending message to Target queue manager via channel is diffrent. So one can not rollback the trascation after putting it in to the MQOUTPUT Node.
Cheers,
Aditya |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Jun 03, 2009 1:51 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| aditya.aggarwal wrote: |
We have faced a similar problem very recently in our environment with very similar Architecture. Target queue was full so the messages start pilling up in to the xmit queue at Broker.
This have created problem in message flow and it starts throwing exception. |
Define a DLQ at the destination queue manager to avoid this problem.
Make sure Xmit queues can hold plenty of messages and your system management alerts on any messages lingering on this queue or arriving on the DLQ. All basic MQ operational practices. |
|
| Back to top |
|
|
| aditya.aggarwal |
| Posted: Wed Jun 03, 2009 2:25 am Post subject: |
|
|
Master
Joined: 13 Jan 2009
Posts: 252
|
Hi Zpat,
DLQ is already defined at Target Queue manager. Xmit queue get filled because the RCVR channel at Target system get stopped after sometime.
Yes We need to improve the MQ monitoring alerts on our systems to avoid this kind of situation in future.
BR,
Aditya |
|
| Back to top |
|
|
| sumit |
| Posted: Wed Jun 03, 2009 3:21 am Post subject: |
|
|
Partisan
Joined: 19 Jan 2006
Posts: 398
|
| aditya.aggarwal wrote: |
| Xmit queue get filled because the RCVR channel at Target system get stopped after sometime. |
How can it stop without a mannual intervention?
Coming back to original poster's problem:
| jamesyu wrote: |
| But for some specific business reason, we don't want to see those messages on DLQ. |
Modify your qmgr definiton to not use DLQ. But you need to be sure that you should be capable enough to handle messages pilling on XMITQ at sending side. May be an alert or big enough maxdepth.
| jamesyu wrote: |
| Instead, we want those messages to be rolled back to its own backout queue. Sounds like this cannot be done. |
I'm not an WMB guy but logically if ur MB flow has processed a message and placed that on XMITQ, for MB it's a successful execution. It won't send messages to backout q.
_________________
Regards
Sumit |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Jun 03, 2009 3:28 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| sumit wrote: |
| ...How can it stop without a mannual intervention?... |
Try reading the manuals and it will tell you. However...
If the receiving queue manager target queue is full, subsequent messages will go to the dead-letter queue of that queue manager. If the dead-letter queue becomes full, want to hazard a guess at where the messages will be? And what effect that may have on a channel?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| bbburson |
| Posted: Wed Jun 03, 2009 1:51 pm Post subject: |
|
|
Partisan
Joined: 06 Jan 2004
Posts: 378
Location: Nowhere near a queue manager
|
| exerk wrote: |
| If the receiving queue manager target queue is full, subsequent messages will go to the dead-letter queue of that queue manager. |
I would amend that to say "... subsequent messages will eventually go to the dead-letter queue..." In a remote queue full situation the sender channel (including cluster sender channels) will go into PAUSED state and retry every so often in case the queue full condition has resolved. This of course delays delivery of all messages to the remote queue manager. A queue that can be addressed remotely from another queue manager than its own should NEVER be allowed to fill up because of this. |
|
| Back to top |
|
|
| aditya.aggarwal |
| Posted: Wed Jun 03, 2009 10:14 pm Post subject: |
|
|
Master
Joined: 13 Jan 2009
Posts: 252
|
Thanks exerk.
bbburson wrote
| Quote: |
| In a remote queue full situation the sender channel (including cluster sender channels) will go into PAUSED state and retry every so often in case the queue full condition has resolved. |
In this situation RCVR Channel will get Stopped and not Paused. We have seen and experience this few days back.
Cheers,
Aditya |
|
| Back to top |
|
|
| exerk |
| Posted: Wed Jun 03, 2009 10:52 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| bbburson wrote: |
| exerk wrote: |
| If the receiving queue manager target queue is full, subsequent messages will go to the dead-letter queue of that queue manager. |
I would amend that to say "... subsequent messages will eventually go to the dead-letter queue..." In a remote queue full situation the sender channel (including cluster sender channels) will go into PAUSED state and retry every so often in case the queue full condition has resolved. |
Unless the PAUSE is so brief that it's of the 'blink and you miss it' variety, I have personally never seen that condition.
| bbburson wrote: |
| ...This of course delays delivery of all messages to the remote queue manager. A queue that can be addressed remotely from another queue manager than its own should NEVER be allowed to fill up because of this. |
I would amend that to say "...This of course delays delivery of all messages to the remote queue manager, via any channel delivering messages to that queue...".
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu Jun 04, 2009 5:26 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| aditya.aggarwal wrote: |
Thanks exerk.
bbburson wrote
| Quote: |
| In a remote queue full situation the sender channel (including cluster sender channels) will go into PAUSED state and retry every so often in case the queue full condition has resolved. |
In this situation RCVR Channel will get Stopped and not Paused. We have seen and experience this few days back.
Cheers,
Aditya |
In this scenario, if the channels goes to PAUSED and when the channel goes to STOPPED depends on if you have a DLQ defined and what the RCVR channel's Message Retry Count is set to.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
