| Author |
Message
|
| Diwakar |
 Posted: Thu Feb 03, 2011 9:07 am Post subject: why can't we define a backout queue? question from infocentr |
 |
|
Apprentice
Joined: 06 Apr 2005
Posts: 33
|
Hi,
Here is an excerpt from the MQ v7 info center :
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/topic/com.ibm.mq.amqwak.doc/ir19630_.htm
-------------------------------------------------------------
On queue managers that do not support the BackoutThreshold and BackoutRequeueQName queue attributes, JMS ConnectionConsumer uses a value of 20 for the backout threshold
-------------------------------------------------------------
What I don't understand is why do some queue managers don't support backout threshold / backout requeue name ? As far as I understand, we should be able to define them on any queues on any queue managers.
Can someone please explain ?
thanks.
_________________
Diwakar. |
|
| Back to top |
|
 |
| Diwakar |
| Posted: Thu Feb 03, 2011 5:30 pm Post subject: |
|
|
Apprentice
Joined: 06 Apr 2005
Posts: 33
|
We use MQ v7.0.1, as the JMS messaging provider for Websphere Process Server v6.0.1. We have just 1 queue manager but 2 clustered process server boxes connected to MQ qmgr using MQ-CLIENT connections. One of the process server boxes hosts the MQ qmgr that is used as the JMS provider. The process servers are essentially used as websphere Application servers for our application. And both are Windows 2003 servers.
We also have a Message Broker v7 instance using MQ v7 on Windows 2008 (64-bit platform).
Here is our topology:
Message Broker v7 <---> Process server v6.0.x (2 boxes and 1 has MQ v7)
We have a webservices-request queue on the process server qmgr that 6 JMS listeners ( 3 on each of the 2 process server boxes) listen on. And all of them read from the single queue instance, and they all insert/update/delete an Oracle database on a remote unix server. And they all put their replies back to a single webservices-reply queue (different from the request queue) on the message broker's qmgr via JMS.
We have default settings on the MQ request queue for backout threshold/requeue values. They are zero and blank respectively. But each of the JMS listeners has a "maximum retries" setting of 1 or more.
In such a scenario, can someone please tell us which settings take precedence (for backout threshold )? the MQ properties on the queue or the JMS setting on the application server's IBM console ?
Thanks
_________________
Diwakar. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Feb 03, 2011 7:35 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Diwakar wrote: |
We have default settings on the MQ request queue for backout threshold/requeue values. They are zero and blank respectively. But each of the JMS listeners has a "maximum retries" setting of 1 or more.
In such a scenario, can someone please tell us which settings take precedence (for backout threshold )? the MQ properties on the queue or the JMS setting on the application server's IBM console ?
Thanks |
Shouldn't be so complex to figure out. They both (settings) go hand in hand. What happens when you hit a poison message? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Diwakar |
| Posted: Thu Feb 03, 2011 8:55 pm Post subject: |
|
|
Apprentice
Joined: 06 Apr 2005
Posts: 33
|
fjb_saper,
"Figuring out" may not give us the correct info always.
In our case, nothing happens when we try with both. I know that could mean we have other issues to look into.
So, I am trying to know which settings take precedence.
_________________
Diwakar. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Feb 04, 2011 9:04 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You are trying to force one setting over the other. That will have its own challenges. As I said you need to have the settings work hand in hand for the optimum result:
- a backout queue specified in MQ
- a backout Thresh >0
- a retry count > backout Thresh on the MDB
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
