| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| How do I send a msg to the dead letter queue |
« View previous topic :: View next topic » |
| Author |
Message
|
| AlexeiSkate |
 Posted: Tue May 21, 2002 3:32 pm Post subject: How do I send a msg to the dead letter queue |
 |
|
Centurion
Joined: 10 Apr 2002
Posts: 123
|
Hi,
While in a loop doing a PUT or a GET, is it correct to check for the msg backoutCount number right after calling a get or put action ? And if the backoutCount number is > 3, for example, how do I then send that msg to the Dead Letter Queue ?
I'm actually just loading the content of a file onto a queue and reading off the queue. Do I need to bother with checking for backout count ? I'm doing both my get and put under syncpoint, so I'm assuming that if something did go wrong in the process, no commit is executed and everything rolls back.
thanks,
Alex |
|
| Back to top |
|
 |
| amurugan |
| Posted: Tue May 21, 2002 4:05 pm Post subject: |
|
|
Voyager
Joined: 10 Sep 2001
Posts: 75
Location: india
|
hi ,
have u set the back out count threshiold value in the queue.If the message reaches the threshold value then it will be put in DLQ .
Regards,
Murugan |
|
| Back to top |
|
|
| StefanSievert |
| Posted: Tue May 21, 2002 6:00 pm Post subject: |
|
|
Partisan
Joined: 28 Oct 2001
Posts: 333
Location: San Francisco
|
Alex,
checking the backout counter of a message only makes sense after a MQGET operation and usually only if your getting application is triggered. This is done to prevent something called a poison message loop where a message that cannot be processed by the application is rolled back to the queue. Usually those applications (ab)end if this happens. If they have been triggered, MQ will re-evaluate the trigger conditions and potentially retrigger the application, causing the same processing to take place over and over again, unless the error condition causing the rollback was a temporary one.
Most of the installations I have seen so far define an application specific error queue as the Backout requeue name and route those poison messages to this queue, should an error occur. But there is principally no reason why you couldn't put them to the DLQ if you wish to do so. The advantage is that you can possibly use the supplied dead-letter queue handler to take care of those msgs. Disadvantages are that you have to construct a dead letter message header (MQDLH) to stick in front of your failed message and that all your failed application messages end up on the same 'error' queue, which can make application specific error handling a bit more trickier.
For both approaches, the processing will not be automatic. You have to MQINQuire the BackoutQueueName and threshold attributes and MQPUT the poison message to the queue if it has reached your threshold. MQ just provides you the information, you have to do the work. 
Hope that helps,
Stefan
_________________
Stefan Sievert
IBM Certified * WebSphere MQ |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue May 21, 2002 6:19 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Muragan,
The threshhold property of the queue is simply there so that an application can do an MQINQ call to the queue and see what that value is. The queue manager takes no action based on this value.
If an app gets a message and sees that its backout count is to high (either it is higher than a hardcoded value in the app or higher than the value it retrieved from the queue property via the MQINQ call), then the Application itself can put the message to some Exception queue. The name of this queue can be hard coded in the app or the app can do an MQINQ call against the queue it just got from to see what the administrators want you to use as an exception queue via the BackoutRequeueQName property.
Alex,
Whenever an MQ application does a GET under syncpoint, it should check the backout count. Because if the app ends abnormally before commiting the message(s) will get placed back on the queue. If the message itself is causing the abend, then you are in a Poisened Message Loop.
Get the next message (Message ABC; backout count is 0)
Abend
Message ABC goes back to the queue.
Get the next message (Message ABC again!; backout count is 1)
Abend
Message ABC goes back to the queue.
Get the next message (Message ABC again!; backout count is 2)
Abend
Message ABC goes back to the queue.
and on and on and on.....
You could put the poisened message to the DLQ if you wanted to; its just a plain old queue. But whenever the QM puts a message there, it adds a Dead Letter Header to the message, so that if there is a DeadLetterHeader Handler running, it will know why the message was put there. If you put messages to the DLQ, you should build that header also.
I would recommend you instead put messages to a Poisened message queue instead. So if your app's regular queue is called ALEX.THISPROJECT.REQUEST, I would create a queue called ALEX.THISPROJECT.EXCEPTION, and put your apps poisened messages there. Maybe trigger that exception queue on first so as soon as a message lands there, you are alerted to the fact that you got problems.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| amurugan |
| Posted: Tue May 21, 2002 7:05 pm Post subject: |
|
|
Voyager
Joined: 10 Sep 2001
Posts: 75
Location: india
|
hi peter ,
thanks for the info . we are actually following the same mechanism as you said for handling poisoned messages |
|
| Back to top |
|
|
| amurugan |
| Posted: Tue May 21, 2002 7:06 pm Post subject: |
|
|
Voyager
Joined: 10 Sep 2001
Posts: 75
Location: india
|
hi peter ,
thanks for the info . we are actually following the same mechanism as you said for handling poisoned messages |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
