| Author |
Message
|
| Rahul999 |
 Posted: Wed Sep 15, 2010 5:23 am Post subject: Message Broker and MQ poison Message |
 |
|
Centurion
Joined: 14 Mar 2007
Posts: 134
|
Hello,
How does Message Broker handles poison messages?
I have seen cases where a message was poisoned and picked by MQInput node and rolled back and keep doing it for infinite time until we manually removed the msg from queue.
Then we find out if we have specified a backout queue name, then in that case the message would have gone to a backout queue after a threshold value has reached.
Does that mean is it always a best practice to specify Backout Requeue for MQInput node IN Queue ?? as Poison message could come at any time and no one wants to have their message flow doing nothing but looping for a single message.
Another doubt I have is - "Does Transaction mode property of a MQInput node plays any part in handling of Poison messages as someone highlighted to me that it plays a part but I am not sure how?"
Regards |
|
| Back to top |
|
 |
| Vitor |
| Posted: Wed Sep 15, 2010 5:28 am Post subject: Re: Message Broker and MQ poison Message |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Rahul999 wrote: |
| Does that mean is it always a best practice to specify Backout Requeue for MQInput node IN Queue ?? as Poison message could come at any time and no one wants to have their message flow doing nothing but looping for a single message. |
It's always best practice to specify a Backout queue for any queue you read from, if it's read by WMB or not. It's likewise best practice for any application to check Backout count against Backout Threshold before attempting any processing of the message; the MQInput node follows this best practice.
| Rahul999 wrote: |
| Does Transaction mode property of a MQInput node plays any part in handling of Poison messages |
Only in so far as WMB's normal UoW processing applies.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Rahul999 |
| Posted: Wed Sep 15, 2010 5:38 am Post subject: |
|
|
Centurion
Joined: 14 Mar 2007
Posts: 134
|
| Quote: |
Rahul999 wrote:
Does Transaction mode property of a MQInput node plays any part in handling of Poison messages
Only in so far as WMB's normal UoW processing applies. |
Thanks Vitor for the reply, by default the Transaction mode property of a MQInput node is set to 'Yes'. Does it matter(as far as Poison message handling is concerned) if we change it to 'No'
Regards |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Sep 15, 2010 5:59 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Rahul999 wrote: |
| Does it matter(as far as Poison message handling is concerned) if we change it to 'No' |
If you're asking will the MQInput node put a poison message on the backout queue if the transaction mode is No, then yes it will. It will also do this if it's Yes or Automatic.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Wed Sep 15, 2010 6:19 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
| Vitor wrote: |
If you're asking will the MQInput node put a poison message on the backout queue if the transaction mode is No, then yes it will. It will also do this if it's Yes or Automatic. |
With the exception of the "yes" setting WMB may not simply move the message to the BOQ. The persistence of the message also needs to be considered when determining if WMB discards the message or if moves it to the backout queue. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Sep 15, 2010 6:24 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| WMBDEV1 wrote: |
| With the exception of the "yes" setting WMB may not simply move the message to the BOQ. The persistence of the message also needs to be considered when determining if WMB discards the message or if moves it to the backout queue. |
Really? That's not what this says & not my experience of it, but does make the point (which I should have earlier) that this whole question of poison messages is obviated if you have the Failure terminal connected.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| WMBDEV1 |
| Posted: Wed Sep 15, 2010 6:37 am Post subject: |
|
|
Sentinel
Joined: 05 Mar 2009
Posts: 888
Location: UK
|
| Vitor wrote: |
| WMBDEV1 wrote: |
| With the exception of the "yes" setting WMB may not simply move the message to the BOQ. The persistence of the message also needs to be considered when determining if WMB discards the message or if moves it to the backout queue. |
Really? That's not what this says & not my experience of it, but does make the point (which I should have earlier) that this whole question of poison messages is obviated if you have the Failure terminal connected. |
Quote from that link:
"The MQInput node takes certain actions when it handles errors with persistent and transactional messages. The node attempts retry processing when a message is rolled back to the input queue. "
If you follow the link at the top of that page you go to http://publib.boulder.ibm.com/infocenter/wmbhelp/v6r1m0/index.jsp?topic=/com.ibm.etools.mft.doc/ac18890_.htm
where you can find this little gem for non-persistant and non transacted stuff:
"◦If you have not connected the Failure terminal, the node logs the error in the local error log and discards the message"
I always found the flow chart on page 6 in this link useful:
http://www.redbooks.ibm.com/redpapers/pdfs/redp4043.pdf
Hope that helps. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Sep 15, 2010 6:46 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| WMBDEV1 wrote: |
where you can find this little gem for non-persistant and non transacted stuff:
"◦If you have not connected the Failure terminal, the node logs the error in the local error log and discards the message" |
Well again my signature is justified. 
Maybe the example I'm thinking of had persistent messages. Not as I remember it, but the years take their toll..... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Rahul999 |
| Posted: Thu Sep 16, 2010 7:43 am Post subject: |
|
|
Centurion
Joined: 14 Mar 2007
Posts: 134
|
Hi Vitor,
Faced a problem today in one of our flows, it was trying to update a database but as the database was full, throws the exception and message went back to MQInput Node, now MQInput node didn't have failure and catch terminal connected(bad design), so message started backing out to InputQ. But as that Q didnt have any backout Q or threshold defined so message again processed and again failed and again goes back to InputQ. I think backout count kept increasing. But, then the messaage started going to DLQ (I found out later from the mqsi.log about this).
I am just wondering how many times did the flow tried to backout the message when it thought of putting into DLQ. As the input queue of that node didnt' had a Backout or Threshold defined, ideally it should have kept tried infinite times. I am not sure how does it work and what makes it to go to DLQ.
Do you have any idea about this? |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Sep 16, 2010 8:04 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Rahul999 wrote: |
| But as that Q didnt have any backout Q or threshold defined so message again processed and again failed and again goes back to InputQ. I think backout count kept increasing. But, then the messaage started going to DLQ (I found out later from the mqsi.log about this). |
I'm clearly the wrong person to be answering this as my knowledge of this area is flawed. But I'm surprised by that behaviour.
| Rahul999 wrote: |
| I am just wondering how many times did the flow tried to backout the message when it thought of putting into DLQ. |
I would have expected just once; 2nd time through the backout count would have exceeded threshold (I'm assuming if you didn't set a queue name, you didn't change the threshold) and WMB would have attempted to put it to the backout queue. As there was none it should have dead lettered it with a reason of MQRC_APPL_FIRST. Or so I;d have though.
| Rahul999 wrote: |
| As the input queue of that node didnt' had a Backout or Threshold defined, ideally it should have kept tried infinite times. |
Ideally? In your ideal world WMB would have kept banging away infinitely until it had melted your disc bearings from the I/O or crashed the box by soaking all the CPU??
In my ideal world software doesn't run wild forever in the hope something will change but gives up and signals a human to help. It's valid to retry (could be a transient error like another application with a table lock) but you were seriously looking for this to bang away until the DBAs gave the database more space? What would have happened if the database server was down for a few hours with hardware problems?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Sep 16, 2010 8:16 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
If a message backout count has reached twice the backout threshold, it is put to the DLQ.
This is documented. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Sep 16, 2010 8:29 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
If a message backout count has reached twice the backout threshold, it is put to the DLQ.
This is documented. |
I said I was the wrong person to answer this.
But I stand by my comments regarding indefatigable software.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Rahul999 |
| Posted: Thu Sep 16, 2010 6:05 pm Post subject: |
|
|
Centurion
Joined: 14 Mar 2007
Posts: 134
|
jeff wrote:
| Quote: |
If a message backout count has reached twice the backout threshold, it is put to the DLQ.
This is documented. |
Jeff,
It is taken from our queue definition:
| Quote: |
ALTTIME(09.35.08 ) BOQNAME( )
BOTHRESH(0) CLUSNL( )
|
now the threshold is 0, what would happen in that case.
Regards |
|
| Back to top |
|
|
| Amitha |
| Posted: Mon Sep 20, 2010 10:43 am Post subject: |
|
|
Voyager
Joined: 20 Nov 2009
Posts: 80
Location: Newyork
|
|
| Back to top |
|
|
| sunny_30 |
| Posted: Thu Nov 14, 2013 4:43 pm Post subject: |
|
|
Master
Joined: 03 Oct 2005
Posts: 258
|
Is the message tried twice the BOTHRESH value, and attempted to put to BOQ (or) DLQ only 'WHEN' failure terminal of MQInput Node is connected and failed in that connection?
It seems to be so, as per this link: http://pic.dhe.ibm.com/infocenter/wmbhelp/v8r0m0/index.jsp?topic=%2Fcom.ibm.etools.mft.doc%2Fac00414_.htm
The writeup on points #1 to #4 is so confusing or may be its just me. #1 and #3 talk about situations where retries reaches BOTHRESH value, but again #4 talks about the value reaching twice the value.. Can some one clear this up please. Thanks |
|
| Back to top |
|
|
|
|
