Barton, Linda
2013-09-20 14:23:42 UTC
Hi, I have a question about how the Backout Queue, Backout Threshold and the rulestable parms play together and how a message we have in the dead letter queue could possibly have a backout count of 365!
App queue - VK.PUB.CLAIMS... HardenGetBackout=HARDENBO
App backout queue VK.PUB.CLAIMS.BACKOUT....
App BOTHRESH(1)
System dead queue - QMGRNAME.DEAD.QUEUE
App dead queue - VK.DLQ.ALIAS
MQ_startup script has this entry: runmqdlq</util/mware/rulestable>/util/mware/mqdlq.log &
rulestable file:
REASON(MQRC_Q_FULL) ACTION(RETRY) RETRY(5)
REASON(MQRC_PUT_INHIBITED) ACTION(RETRY) RETRY(5)
DESTQ(VK*) +
ACTION(FWD) FWDQ(VK.DLQ.ALIAS) +
FWDQM(&DESTQM) HEADER(YES) PUTAUT(DEF)
DESTQ(VK*) +
ACTION(FWD) FWDQ(VK.DLQ.ALIAS) +
FWDQM(&REPLYQM) HEADER(YES) PUTAUT(DEF)
First, the application queue has a BOQNAME specified and a BOTHRESH of 1.
Second the rulestable has a retry count of 5 and takes the default interval of 60 for the retry interval for a queue full condition before it moves it from the DEAD queue to an application dead letter queue.
I would think that the first condition that would get hit is the BOQNAME and BOTHRESH of 1 - which moves a message off the application queue, to the backout queue specified on its definition. I would expect the BackoutCount to be 1 at this point for the failed MQGET, but for most of our messages in backout queues, the BackoutOutCount is 0. Not sure why that happens...
The application backout queue filled up so the message would be sent to the system DEAD.QUEUE.
Does the BackoutCount in the header get incremented for this action? There must be an MQGET from the app backout queue and a MQPUT to the DEAD queue. So the only time I would expect it to increment the Backoutcount is if it fails to put it to the DEAD queue. If that is true, a regular move to the DEAD queue does not increment the backout count. So BackoutCount would still be 1 at this point
Now I would expect the rulestable to kick in and if the message is on the system DEAD queue because the app queue is full, it would retry it 5 times at 60 second intervals and if it still fails, it would forward it to the queue we specified in the Action - the application dead letter queue - VK.DLQ.ALIAS. I would not expect the BackoutCount to be increased for this action, BackoutCount is still 1.
At some point, DEAD.QUEUE fills up. Now the GETS from the app backout queue will fail because it cannot put to the DEAD queue. This must be where the Backout count goes crazy. Does MQ go in to a holding pattern while the DEAD queue is full? I think I have seen it do that.
Meanwhile, the rulestable is moving the messages from the DEAD queue to the VK.DLQ.ALIAS local queue. I can only imagine the nightmare if the VK.DLQ.ALIAS local queue filled up and then the messages tried to go to the full DEAD queue. I imagine MQ would stop processing at this point.
So now the message tries to go to the full DEAD.QUEUE and the rulestable kicks in again. Does the BackoutCount get incremented every time it tries to move it to the VK.DLQ.ALIAS and fails? Would it go in an endless loop between the DEAD queue and the DLQ? When does it stop trying?
Linda Barton
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
App queue - VK.PUB.CLAIMS... HardenGetBackout=HARDENBO
App backout queue VK.PUB.CLAIMS.BACKOUT....
App BOTHRESH(1)
System dead queue - QMGRNAME.DEAD.QUEUE
App dead queue - VK.DLQ.ALIAS
MQ_startup script has this entry: runmqdlq</util/mware/rulestable>/util/mware/mqdlq.log &
rulestable file:
REASON(MQRC_Q_FULL) ACTION(RETRY) RETRY(5)
REASON(MQRC_PUT_INHIBITED) ACTION(RETRY) RETRY(5)
DESTQ(VK*) +
ACTION(FWD) FWDQ(VK.DLQ.ALIAS) +
FWDQM(&DESTQM) HEADER(YES) PUTAUT(DEF)
DESTQ(VK*) +
ACTION(FWD) FWDQ(VK.DLQ.ALIAS) +
FWDQM(&REPLYQM) HEADER(YES) PUTAUT(DEF)
First, the application queue has a BOQNAME specified and a BOTHRESH of 1.
Second the rulestable has a retry count of 5 and takes the default interval of 60 for the retry interval for a queue full condition before it moves it from the DEAD queue to an application dead letter queue.
I would think that the first condition that would get hit is the BOQNAME and BOTHRESH of 1 - which moves a message off the application queue, to the backout queue specified on its definition. I would expect the BackoutCount to be 1 at this point for the failed MQGET, but for most of our messages in backout queues, the BackoutOutCount is 0. Not sure why that happens...
The application backout queue filled up so the message would be sent to the system DEAD.QUEUE.
Does the BackoutCount in the header get incremented for this action? There must be an MQGET from the app backout queue and a MQPUT to the DEAD queue. So the only time I would expect it to increment the Backoutcount is if it fails to put it to the DEAD queue. If that is true, a regular move to the DEAD queue does not increment the backout count. So BackoutCount would still be 1 at this point
Now I would expect the rulestable to kick in and if the message is on the system DEAD queue because the app queue is full, it would retry it 5 times at 60 second intervals and if it still fails, it would forward it to the queue we specified in the Action - the application dead letter queue - VK.DLQ.ALIAS. I would not expect the BackoutCount to be increased for this action, BackoutCount is still 1.
At some point, DEAD.QUEUE fills up. Now the GETS from the app backout queue will fail because it cannot put to the DEAD queue. This must be where the Backout count goes crazy. Does MQ go in to a holding pattern while the DEAD queue is full? I think I have seen it do that.
Meanwhile, the rulestable is moving the messages from the DEAD queue to the VK.DLQ.ALIAS local queue. I can only imagine the nightmare if the VK.DLQ.ALIAS local queue filled up and then the messages tried to go to the full DEAD queue. I imagine MQ would stop processing at this point.
So now the message tries to go to the full DEAD.QUEUE and the rulestable kicks in again. Does the BackoutCount get incremented every time it tries to move it to the VK.DLQ.ALIAS and fails? Would it go in an endless loop between the DEAD queue and the DLQ? When does it stop trying?
Linda Barton
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html