| Author |
Message
|
| siji1717 |
 Posted: Wed Oct 31, 2007 2:10 pm Post subject: Backout queue clustering |
 |
|
Newbie
Joined: 31 Oct 2007
Posts: 2
|
Can we have a Backout queue clustered..As of now the rogue messages is looping through and not getting written to the Clustered Backout queue in another Queue Manager..
Can someone tell whetehr Backout queues can be clustered.. |
|
| Back to top |
|
 |
| mvic |
| Posted: Wed Oct 31, 2007 3:15 pm Post subject: Re: Backout queue clustering |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| siji1717 wrote: |
Can we have a Backout queue clustered..As of now the rogue messages is looping through and not getting written to the Clustered Backout queue in another Queue Manager..
Can someone tell whetehr Backout queues can be clustered.. |
It can be clustered, but whether it should be clustered is another matter (see below). A backout queue is just a queue. MQ code won't write your message to it; it's the responsibility of your app code to find its name (from the main queue definition), and call MQPUT1, etc..
(Yes, it's true that JMS, XMS, or WebSphere Message Broker might put these to the backoutQ for you - this behaviour is documented in the relevant product manuals. But the core queue manager functionality only treats the BackoutRequeueQ and BackoutThreshold as information to be controlled by the administrator and available for the use of the application if it so desires).
I am unaware of patterns for backout queues relating to cluster setups - hopefully someone will come along and add the benefit of experience on that, or perhaps give a reference into the manuals that I missed. But at first sight it seems to me that there should be a backoutQ local to the getting application, to speed the handling of such a message. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Oct 31, 2007 7:56 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
On top of this even if you cluster the backout queue you still need to specify it on each instance of the main queue. Remember: you can only get messages from a queue that's local to the qmgr you're connected to.
So that local queue needs to hold the reference to the backout queue, whether that (backout) queue be clustered or not.
In the case of a clustered main queue, each instance needs to have the backout queue specified in it as well as the bothreshold.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| siji1717 |
| Posted: Wed Oct 31, 2007 8:08 pm Post subject: |
|
|
Newbie
Joined: 31 Oct 2007
Posts: 2
|
Thanks..But one question if the Broker Queue Manger has universal access to all queue managers in that cluster so why should we have an instance of the Backout queue in the Broker queue manager since it can write to any queue in a given cluster..I have some error queues defined like that ..
Does recycling the reporsitory cluster on the queue manager help.. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Nov 01, 2007 4:52 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
If the message flow is looping and failing to put to the backout queue, then it's more likely that the BOTHRESH is not specified or has not been reached. Or you have coded your flow in such a way that backout processing doesn't occur - like wiring the failure terminal.
In the case where Broker tried to put the message to the backout queue and failed, a) there will be error messages on the log, b) the message will go to the DLQ if defined.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Nov 01, 2007 4:54 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Also, there's no technical reason why a backout queue has to be local - unless the program trying to do the backout has to do an Inquire on the backout queue.
But it's an extra place that an error can occur, that will prevent the message from being rolled back. So it's "riskier" in that sense. More opportunity for failure or delay.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
