| Author |
Message
|
| dgolding |
 Posted: Wed Aug 20, 2008 5:32 am Post subject: ignoring BackoutCount in IBM JMS - MQMessageConsumer |
 |
|
Yatiri
Joined: 16 May 2001
Posts: 668
Location: Switzerland
|
| I've tried setting the BOTHRESH on the queue to a silly high value but the application still rejects the message. Is this Redelivery Count or whatever the parameter is set with a default value in JMS? |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed Aug 20, 2008 3:02 pm Post subject: Re: ignoring BackoutCount in IBM JMS - MQMessageConsumer |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| dgolding wrote: |
| I've tried setting the BOTHRESH on the queue to a silly high value but the application still rejects the message. Is this Redelivery Count or whatever the parameter is set with a default value in JMS? |
I have seen the application honoring the BOTHRESH but it does need to check it against the Redelivery Count on the message.
WAS will move the message to the Backout/DLQ. On standalone apps you might have to implement this yourself. Checking the BOTHRESH might involve the MS0B package...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| dgolding |
| Posted: Thu Aug 21, 2008 2:54 am Post subject: |
|
|
Yatiri
Joined: 16 May 2001
Posts: 668
Location: Switzerland
|
Hi, thanks for that fjb_saper. What I can't understand is that the developer insists that he has not coded the backout behaviour, and here's a comment I found in the ibm.software.websphere.mq.programming
| Quote: |
The queue manager will NEVER do anything with a message
based on the backout threshold count. Everything must be dealt with at
the application level. |
(From our own illustrious Roger Lacroix no less)
So who is doing it? It was always my understanding that all MQ does is increment the backout count, and everything else is done by application itself, but is JMS being clever here? It's not even a RFH2 message...  |
|
| Back to top |
|
|
| JLRowe |
| Posted: Thu Aug 21, 2008 4:58 am Post subject: |
|
|
Yatiri
Joined: 25 May 2002
Posts: 664
Location: South East London
|
Are you running in J2EE?
A message driven bean has it's own settings, it ignores the MQ max redelivery count (since not all JMS providers have this feature) |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Aug 21, 2008 6:22 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| dgolding wrote: |
Hi, thanks for that fjb_saper. What I can't understand is that the developer insists that he has not coded the backout behaviour, and here's a comment I found in the ibm.software.websphere.mq.programming
| Quote: |
The queue manager will NEVER do anything with a message
based on the backout threshold count. Everything must be dealt with at
the application level. |
(From our own illustrious Roger Lacroix no less)
So who is doing it? It was always my understanding that all MQ does is increment the backout count, and everything else is done by application itself, but is JMS being clever here? It's not even a RFH2 message... |
2 experiences I have seen work
a) WAS MDB just set the bothresh and everything is automatic. No BOQ means the message goes to the DLQ with RC 2362
b) Standalone JMS on solaris. Every receive brings up an error. Problem is the app did not have the rights to post to the SYSTEM.DEAD.LETTER.QUEUE which was the qmgr's DLQ, and the bothresh < redelivery count. So make sure each JMS app has the authority to post to the DLQ.
Hope it helps some.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| dgolding |
| Posted: Wed Sep 17, 2008 3:33 am Post subject: |
|
|
Yatiri
Joined: 16 May 2001
Posts: 668
Location: Switzerland
|
An update on this, if anybody is interested:
I opened a ticket with IBM and apparently it's a feature  If you open an alias queue and get a message with a Backout count > 0 MQ tries to read the backout threshold from the base local queue. If (as we do) the application has no authority to the base queue it assumes the default of 20 and the default backout queue as the System DLQ - so the put fails with a 2035.
so far, so good - but not ideal as all the Backout info is "hidden" from the application as per most normal security rules (maybe we could give the app INQ authority) but doesn;t explain when we gave ALL authority to the local queue to the App, it still tried (and failed) to put the poison message on the DLQ!
This could well be an application error and I will chase up with developer just as soon as he comes back off holiday |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Sep 17, 2008 8:02 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| dgolding wrote: |
An update on this, if anybody is interested:
I opened a ticket with IBM and apparently it's a feature If you open an alias queue and get a message with a Backout count > 0 MQ tries to read the backout threshold from the base local queue. If (as we do) the application has no authority to the base queue it assumes the default of 20 and the default backout queue as the System DLQ - so the put fails with a 2035.
so far, so good - but not ideal as all the Backout info is "hidden" from the application as per most normal security rules (maybe we could give the app INQ authority) but doesn;t explain when we gave ALL authority to the local queue to the App, it still tried (and failed) to put the poison message on the DLQ!
This could well be an application error and I will chase up with developer just as soon as he comes back off holiday |
The app will need INQ authority for the base queue and POST authority for the DLQ / Backout Q. Remember JMS authority is not just POST but POST+INQ
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
