| Author |
Message
|
| Lucky |
 Posted: Wed Apr 15, 2009 9:32 pm Post subject: Failed msgs went to DLQ instead of defined Err queue |
 |
|
Apprentice
Joined: 06 Feb 2007
Posts: 35
|
Hi All,
I have an interface where any exceptions in main flow are navigated to Catch terminal. And in this path msg causing exception is send to ABC.ERR queue & exception details are transformed and sent to support.
Input queue don’t have its backout q defined.
Problem is: when a msg is failed in prod, instead of going msgs to ABC.ERR queue it went to DLQ.
Observed that Queue was correctly defined in the QMGR and queue was also not full.
When replicated the scenario on dev environment, msg properly went to ABC.ERR queue. What else might be reason behind msg going to DLQ on prod.
Please provide your ideas on how debug this issue. |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Apr 16, 2009 12:00 am Post subject: Re: Failed msgs went to DLQ instead of defined Err queue |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Lucky wrote: |
| What else might be reason behind msg going to DLQ on prod. |
It will be the reason quoted in the DLH on the message in question.
| Lucky wrote: |
| Please provide your ideas on how debug this issue. |
Examine the message on the DLQ to determine why it's there.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Lucky |
| Posted: Thu Apr 16, 2009 4:47 am Post subject: |
|
|
Apprentice
Joined: 06 Feb 2007
Posts: 35
|
Reason quoted in the DLH is "65536". What does this mean? any idea?
Please help!!! |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Apr 16, 2009 5:03 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Lucky wrote: |
Reason quoted in the DLH is "65536". What does this mean? any idea?
|
It's a broker abend; or from WMQ's perspective an application defined error. In the absense of a backout queue, there's nowhere for it to go but to the DLQ.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Lucky |
| Posted: Thu Apr 16, 2009 8:10 pm Post subject: |
|
|
Apprentice
Joined: 06 Feb 2007
Posts: 35
|
Vitor,
Let me put the in detail how my msg flow is behaving.
Msg flowing in getting failed, & Catch & failure of MQInput node is connected to same exceptional handling.
Catch, Failure path does this: Puts original msg to ABC.ERR queue & exception+few msg details to SERVICE queue for support.
So, when error is occured in main path its navigating to catch path & msg is put to ABC.ERR, while creating msg for SERVICE queue another exception is occured. And now its thrown to Failure terminal.
Same instance reoccurs as catch, Failure connected to same set of nodes.
When exception occurs from failure path when its thrown to MQInput node as there is no backout queue & threshold are defined, thats the reason msg is going to DLQ?
Then, Why is the flow behaving differently on development env? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Apr 16, 2009 8:42 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Lucky wrote: |
Vitor,
Let me put the in detail how my msg flow is behaving.
Msg flowing in getting failed, & Catch & failure of MQInput node is connected to same exceptional handling.
Catch, Failure path does this: Puts original msg to ABC.ERR queue & exception+few msg details to SERVICE queue for support.
So, when error is occured in main path its navigating to catch path & msg is put to ABC.ERR, while creating msg for SERVICE queue another exception is occured. And now its thrown to Failure terminal.
Same instance reoccurs as catch, Failure connected to same set of nodes.
When exception occurs from failure path when its thrown to MQInput node as there is no backout queue & threshold are defined, thats the reason msg is going to DLQ?
Then, Why is the flow behaving differently on development env? |
Because in DEV the error is not occurring at the same place.
What would your flow do if the error occurs while in the MQInput node?
What does your broker log have to say?
Any abend files in /var/mqsi/common/errors? 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Apr 16, 2009 11:23 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Lucky wrote: |
When exception occurs from failure path when its thrown to MQInput node as there is no backout queue & threshold are defined, thats the reason msg is going to DLQ?
|
Exactly so. Whatever you have in the last part of your error handling (from a design viewpoint) should be as simplistic as possible to prevent this last ditch effort abending itself.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Apr 16, 2009 11:26 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Lucky wrote: |
| Then, Why is the flow behaving differently on development env? |
If your dev environment is the same as your production one, it'll be a rare and beautiful thing. 
Assuming it's just a dev environment, which may or may not have the same version of code as prod (depending on your source code control & development schedule) but is a copy prod for diagnostic purposes, it could still have subtle differences.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| joebuckeye |
| Posted: Fri Apr 17, 2009 8:30 am Post subject: |
|
|
Partisan
Joined: 24 Aug 2007
Posts: 365
Location: Columbus, OH
|
| Quote: |
| Msg flowing in getting failed, & Catch & failure of MQInput node is connected to same exceptional handling. |
Isn't this a bad idea?
Shouldn't the Catch terminal be where you try to recover from the exception and the Failure terminal left for messages where you can't handle them?
We keep our Failure terminal wired straight to an MQOutput node because we don't want that to fail (outside of any MQ env issues) and send messages to the DLQ. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Apr 17, 2009 8:35 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| joebuckeye wrote: |
| We keep our Failure terminal wired straight to an MQOutput node because we don't want that to fail (outside of any MQ env issues) and send messages to the DLQ. |
Standard practice is to wire the Catch terminal, eventually, to a Throw node and leave the Failure terminal unconnected - at least on MQInput.
Then you get standard retry logic from the MQInput node, including backout retry and backout requeue.
And as a side note, you might be horrified at what happens if the queue your MQOutput is wired to is put-disabled or full or corrupt. |
|
| Back to top |
|
|
|
|
