| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Poison messages |
« View previous topic :: View next topic » |
| Author |
Message
|
| masteringmq |
 Posted: Wed Jan 28, 2009 11:27 pm Post subject: Poison messages |
 |
|
Master
Joined: 20 Oct 2008
Posts: 200
|
| Quote: |
| Sometimes, a badly-formatted message arrives on a queue. Such a message might make the receiving application fail and back out the receipt of the message. |
I discovered that my application processes are being killed due to poison messages. So I apply the following steps:
1. Purge the queue.
2. Change the message data from ASCII to BIN
How do I filter out a couple of poison messages out of 5000 messages sitting in a local queue waiting to be consumed by the application?. This poison messages are sent by someone. |
|
| Back to top |
|
 |
| Mr Butcher |
| Posted: Wed Jan 28, 2009 11:34 pm Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
If a message was backed out the backout counter of that messge is increased. so application logic could be like that:
| Code: |
loop on messages
get message
if end-of-queue then leave
if backout counter > x then
put message to backout or error queue
else
process message
endif
endloop |
x is the max. number of tries to process the message... of course you need something that restarts your application after failure.
i would not recommend to purge messages, just because the program fails. they may still be important for the application or business people.
another possibility is, to make sure your program checks the message content before processing, so it does not fail if the message is not as expected.
_________________
Regards, Butcher |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jan 29, 2009 12:35 am Post subject: Re: Poison messages |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| masteringmq wrote: |
I discovered that my application processes are being killed due to poison messages. So I apply the following steps:
1. Purge the queue.
2. Change the message data from ASCII to BIN
|
You missed out step 1a - "be slaughtered by business users who've just lost 4998 perfectly good messages".
I'm also interested in your comment "Change the message data from ASCII to BIN" - I presume you mean from STRING to NONE in the MQMD as that's the only description WMQ has of the data. How is this going to make one iota of difference to your application code failing to process the message? WMQ has no problem with the message, and your application will receive the same data into it's buffer that failed last time. The only possible change is that this time the data might fail to be converted into the right code page, reducing your application's chances of successfully processing it.
| masteringmq wrote: |
| How do I filter out a couple of poison messages out of 5000 messages sitting in a local queue waiting to be consumed by the application?. This poison messages are sent by someone. |
By properly understanding what a poison message is rather than picking up a single line of text! A poison message is any message unable to be processed by the application and may be perfectly well formed. You can't "filter out" poison messages from the queue, but need appropriate logic (as suggested by my most worthy associate) to handle such messages correctly.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| masteringmq |
| Posted: Thu Jan 29, 2009 5:43 pm Post subject: |
|
|
Master
Joined: 20 Oct 2008
Posts: 200
|
| Yes exactly, if I were to purge 5000 messages the whole transfer will be considered failed. In the context of BIN and ASCII, this is associated with file transfer. Since tools like TDE leverages on MQSeries for file transfer, therefore in the TDE settings you can specify weather should the file transfer be ASCII or BIN. I believe this will be reflected on the data that the messages are carrying. Bad data can cause the receiving application processes to be killed. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jan 29, 2009 7:14 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Please refer to the APG and APR for description of the backout count, backout requeue queue name, and backout threshold.
Poison messages are messages that the consuming application decides (through appropriate business logic) do not meet the requirements for successful processing. For example, a time-card arrives in an intentory request queue. The message may be perfectly valid, but not for the consuming application.
In MQ-speak, a poison message is MQBACKed back into the queue from where it was MQGETted. At the same time, the MQBACK call undoes all changes in the Unit of Work. The problem with this method? It puts the bad message back into the queue for the application to re-MQGET, and discover that it is bad and MQBACK it again, and again, and again.
The usual method of dealing with a so-called poison message is to eventually move it to another queue for special handling.
A well-crafted application will look at the backout count field after each MQGET to discover if this message has already been backed out; then compare the count to the backout threshold set for this queue; then, if the backout count exceeds the threshold, it (the application) will MQPUT the message on some other queue.
Under what circumstances a message becomes poison is strictly an application issue. Likewise, what special processing needs to be done with a poison message is strictly an application issue.
Lacking any specification, I prefer to invert random bits in the message, divide by the time-of-day, and place it in the default xmit queue - like the Tribbles episode of StarTrek. But if you would rather turn ASCII into BIN...
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| masteringmq |
| Posted: Sun Feb 01, 2009 10:28 pm Post subject: |
|
|
Master
Joined: 20 Oct 2008
Posts: 200
|
| In regards to BIN and ASCII, the content of the file is in BIN. But then ASCII was used for the File transfer. To ensure that no data translation is performed the file transfer setting is changed to BIN. This will avoid the receiving application processes to be killed. Yes for sure we can handle the poison messages. But then if one message is missing then the receiving application wont be able to construct the file. This indicates that the file transfer has failed. |
|
| 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
|
|
|
|
