| Author |
Message
|
| SureshAlagarsamy |
 Posted: Thu Jul 26, 2007 10:20 pm Post subject: Problem in my runmqdlq rules script |
 |
|
Novice
Joined: 22 Apr 2007
Posts: 17
|
My rules file:
INPUTQ(SYSTEM.DEAD.LETTER.QUEUE) INPUTQM(QM.DYS2T1) RETRYINT(5) WAIT(YES)
REASON(65536) ACTION(RETRY) RETRY(2)
ACTION(FWD) FWDQ(TESTFLOWIN) HEADER(YES)
Problem:
The runmqdlq keeps on retrying indefinitely as the target queue is put inhibited. The last line which I handle to clear them after retry limit exceeds doesn't seems to work. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri Jul 27, 2007 12:47 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
The problem here is not the last line in your script it is the first.
Set the DLQ to get inhibited. This should stop the DLQ handler. Then set it back to get allowed.
Change your first line to WAIT(NO)
Delete the last line.
Restart the DLQ handler.
You need to think about how the DLQ handler works... Your last line will never get invoked... for the messages with reason(65536). It will however get invoked for any other reason code...
After retrying (twice) the message is put back on the DLQ (with reason code 65536?) and the cycle runs again....
You say the target queue is put inhibited. But this is not what the reason code says... it looks like a broker reason code...
So if the broker's flow target is put inhibited the message will come back to the DLQ with the same 65536 RC. Hence the infinite loop... And have no doubt about it: this is not the flow output message (it was never written as it received the put inhibited rc), it is the flow input message (in absence of a failure terminal). So you put the message back on the queue, the flow tries to process it and it goes back to the DLQ....
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| SureshAlagarsamy |
| Posted: Sun Jul 29, 2007 8:35 pm Post subject: |
|
|
Novice
Joined: 22 Apr 2007
Posts: 17
|
Many Thanks for your reply. It's exactly the right thing whatever you have predicted.
My test scenario is as below,
MQInput Node --> MQOutput Node(Queue PUT inhibited).
When I post a message to the above message flow, since I haven't handled the MQinput node failure terminal, the message falls into the dead letter queue with MQMD headers populated.The reason code was 65536 as you said.
My intention here is to run the dlqhandler to retry 2 times to post to the flow and when still the message fails, I want to forward them to some other local queue.
When I use the reason 65536, the retry action uses the MQDEAD.DestQName for its action which is the queue specified in the MQInput node and hence succeeds in its action. As the message again falls into DLQ, the handler runs recursively and that was the problem I have posted in this forum.
I like to have suggestion from you on how to address(using runmqdlq) the retry based on various reason codes and finally when I still get messages in DLQ, I need to forward them to some other local queue to control the infinite loop. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jul 30, 2007 2:42 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| SureshAlagarsamy wrote: |
Many Thanks for your reply. It's exactly the right thing whatever you have predicted.
My test scenario is as below,
MQInput Node --> MQOutput Node(Queue PUT inhibited).
When I post a message to the above message flow, since I haven't handled the MQinput node failure terminal, the message falls into the dead letter queue with MQMD headers populated.The reason code was 65536 as you said.
My intention here is to run the dlqhandler to retry 2 times to post to the flow and when still the message fails, I want to forward them to some other local queue.
When I use the reason 65536, the retry action uses the MQDEAD.DestQName for its action which is the queue specified in the MQInput node and hence succeeds in its action. As the message again falls into DLQ, the handler runs recursively and that was the problem I have posted in this forum.
I like to have suggestion from you on how to address(using runmqdlq) the retry based on various reason codes and finally when I still get messages in DLQ, I need to forward them to some other local queue to control the infinite loop. |
Set up a backout threshold of 2 (or 3 ... test it) and a backout queue for the queue in the MQInput node, and this should happen automatically for you.
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| SureshAlagarsamy |
| Posted: Mon Jul 30, 2007 4:03 am Post subject: |
|
|
Novice
Joined: 22 Apr 2007
Posts: 17
|
Yes I agree but I have 56 or more application queues and is it feasible to add another set of backout queues?.
I thought it would be great I could able to do this using dlqhandler which perform the retry and when it fails forwading to a single local queue for manual handling.
Thanks for your information. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jul 30, 2007 4:07 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
It's not best practice to use the DLQ for retry handling. Use the backout on the original queue as fjb_sapersuggests, which is intended for this purpose.
And if you decide you must use a DLQ, don't use the one defined to the queue manager. Leave that for properly undeliverable messages.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Jul 30, 2007 11:38 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| Vitor wrote: |
| And if you decide you must use a DLQ, don't use the one defined to the queue manager. |
If you don't use the qmgr defined DLQ, then you're having to write your own code to put the message to a specific queue. This isn't any different than using the Backout Queue - except, perhaps, that one is also writing code to add a DLQ header.
I don't see why it makes sense to do that, instead of using a backout queue.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jul 30, 2007 1:46 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| jefflowrey wrote: |
| Vitor wrote: |
| And if you decide you must use a DLQ, don't use the one defined to the queue manager. |
If you don't use the qmgr defined DLQ, then you're having to write your own code to put the message to a specific queue. This isn't any different than using the Backout Queue - except, perhaps, that one is also writing code to add a DLQ header.
I don't see why it makes sense to do that, instead of using a backout queue. |
Because it will allow you to forward them from the DLQ to a queue where people look at the messages and allow you to treat them as a batch running a DLQ handler on the queue where the messages have been inspected by a human...
So if you have found problem 1 you can run the DLQ handler and get rid of problem 1 going on to problem 2...
A backout queue does not allow for that many options...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Jul 30, 2007 2:06 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
A BOQ should be a queue where people look at the messages.
And can be processed by a batch job.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
