| Author |
Message
|
| jeevan |
 Posted: Thu Jan 10, 2008 11:17 am Post subject: Interesting problem |
 |
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
Recently, one of our applications started using backout queue. As far as I know, the main purpose of this was to present listener going down when there is problem in redeaing message ( after number try reaches at mdb), the listener goes down. In order to prevent that, it was decided to use backout queue.
The creation of backout queue is very recent( I have a post regarding one issue on creaing clustered backout queue which can be seen in this forum) However, there has to be some message there as there have been some roll back activities in mdb. But there are not any messages in backout queue. While discussing, it came out that these message are expiry message. Is not this very interesting.
It is interesting because what happens when the message are backed out? The threshhold count is set to 1. When the messages are rolled back due to any reason, the message are backed out. The backout counts increases to 1.
Now, there are messages in the queue with backout count 1
They are expiry message which requires being read to get deleted.
In this scenario, should not these message be put in the backout queue? As there is not any mesasge read off the backout queue yet, should not we fiind the messages there?
or the mq reading activities get these messages get deleted?
I hope someone might have been dealth with this scenario? I would appreciate any comments/feeback/sharing
thanks a lot
Last edited by jeevan on Thu Jan 10, 2008 11:22 am; edited 1 time in total |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Thu Jan 10, 2008 11:22 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
The messages have an expiry set and will expire on the backout queue.
V6 has a background expiry task.
So depending on WHEN you look you may never see a message on the backout queue...
Working as designed...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| jeevan |
| Posted: Thu Jan 10, 2008 11:24 am Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| fjb_saper wrote: |
The messages have an expiry set and will expire on the backout queue.
V6 has a background expiry task.
So depending on WHEN you look you may never see a message on the backout queue...
Working as designed...
Enjoy |
Means, these message get deleted without being read ( My understanding was or i have read somewhere that when these messages are being read get deleted that time)
Is there any way, we can figure it out that mq moved these message to backout queue? Just curious
thanks |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jan 10, 2008 11:50 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jeevan wrote: |
| My understanding was or i have read somewhere that when these messages are being read get deleted that time |
Quite true under v5.3 - it's one of the changes for v6.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jan 11, 2008 8:30 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| jeevan wrote: |
Is there any way, we can figure it out that mq moved these message to backout queue? Just curious
thanks |
MQ did not move the messages to the backout q, the application did.
The enque count will go up by 1 everytime a messgae is put to a q, assuming you have Performance Events turned on at the QM level.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jeevan |
| Posted: Fri Jan 11, 2008 10:53 am Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| PeterPotkay wrote: |
| jeevan wrote: |
Is there any way, we can figure it out that mq moved these message to backout queue? Just curious
thanks |
MQ did not move the messages to the backout q, the application did.
The enque count will go up by 1 everytime a messgae is put to a q, assuming you have Performance Events turned on at the QM level. |
Peter,
Thanks for reply.
There is not code in application to move the message. Also, it is it MQ's job to move the message when it seems the backout count reaches equal to backout threshhold
I am really confused. |
|
| Back to top |
|
|
| bower5932 |
| Posted: Fri Jan 11, 2008 11:28 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| jeevan wrote: |
| There is not code in application to move the message. Also, it is it MQ's job to move the message when it seems the backout count reaches equal to backout threshhold |
If you are talking about the base WMQ Product, there is NOT code to automatically move messages to the backout queue.
If you are doing something with MDBs inside of the App Server, there are situations where messages are moved to the backout queue. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jan 11, 2008 11:41 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| jeevan wrote: |
| Also, it is it MQ's job to move the message when it seems the backout count reaches equal to backout threshhold |
To back up what bower5932 just said...
It is, and always has been the application's job to deal with Backout Thresholds and Backout Queues.
The qmgr will only do rollback of a GET, it won't do backout.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| jeevan |
| Posted: Fri Jan 11, 2008 12:38 pm Post subject: |
|
|
Grand Master
Joined: 12 Nov 2005
Posts: 1432
|
| jefflowrey wrote: |
| jeevan wrote: |
| Also, it is it MQ's job to move the message when it seems the backout count reaches equal to backout threshhold |
To back up what bower5932 just said...
It is, and always has been the application's job to deal with Backout Thresholds and Backout Queues.
The qmgr will only do rollback of a GET, it won't do backout. |
I should have read this article which I have printed and put on my desk.
| Quote: |
If a message on a private queue cannot be processed and a rollback is issued, that message goes back to the top of the queue. The next MQGET for that queue will pick the problem message up and try to process it again. If that attempt fails and the transaction is rolled back, the message once again goes to the top of the queue. WebSphere MQ maintains a backout count that can notify an application when it is looping on the same message. If the application ignores the backout counter, the first indication of a poison message is that a queue depth begins rising and the getting processes continues to run.
On a shared queue, when there are multiple server processes running, queue depth may not increase dramatically, because when the poison message is being processed, other messages from the queue are being picked up and processed. There is just a rogue message, which keeps getting processed over and over again – eating up CPU cycles, but not stopping work.
In some cases, backing a message out and allowing a few processing attempts is reasonable. For example, if a database row or table is unavailable, it may become available the next time the message is processed.
A well-behaved application will check the backout count on every message read, and if it is non-zero, compare it to the backout threshold defined on the queue. If the count is greater than the threshold, the message should be written to the queue specified in the BOQNAME parameter and committed. Often a Dead Letter Header (MQDLH) is attached to the message to indicate why the message was written to the backout queue.
|
I think I understand now. Thank you very much all of you guys. Have a wonderful weekend |
|
| Back to top |
|
|
| venusboy |
| Posted: Fri Mar 28, 2008 10:54 am Post subject: |
|
|
Acolyte
Joined: 11 Jun 2002
Posts: 51
|
Hello,
That has always been my assumation (with the native WMQ API), but maybe I mis-understand what is meant by the application responablity to code around it.
But I have just had an exception in a standalone JMS application (not part of an App server/MDB etc):
javax.jms.JMSException: MQJMS1079: Unable to write message to dead letter queue
at com.ibm.mq.jms.services.ConfigEnvironment.newException(ConfigEnvironment.java:567)
at com.ibm.mq.jms.MQMessageConsumer.deadLetter(MQMessageConsumer.java:4387)
at com.ibm.mq.jms.MQMessageConsumer.removeBadMessage(MQMessageConsumer.java:4654)
at com.ibm.mq.jms.MQMessageConsumer.getMessage(MQMessageConsumer.java:3470)
at com.ibm.mq.jms.MQMessageConsumer.receiveInternal(MQMessageConsumer.java:2817)
at com.ibm.mq.jms.MQMessageConsumer.receiveNoWait(MQMessageConsumer.java:2657)
I understand why it cannot write to the DLQ (authority issues), but this means that the IBM JMS implemention is performing the deadletter put.
So is this only in JMS and what version of JMS (recently upgraded to MQv6)? |
|
| Back to top |
|
|
| venusboy |
| Posted: Fri Mar 28, 2008 11:17 am Post subject: |
|
|
Acolyte
Joined: 11 Jun 2002
Posts: 51
|
| Also if I open up the com.ibm.mqjms.jar for v5 then there is no method for the deadLetter. So did I miss something in IBMs migration document for JMS? |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Fri Mar 28, 2008 11:19 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
Well, since this is Java, just be sure to connect to the QMGR with a blank ID and you will not have permission issues unless your MQ Admin has secured your channel.
In any case, the MQ Admin should grant you permission to put, browse, inquire and display the DLQ. Otherwise, they are on the hook to figure out problems.
On the version issue, you should have the full WMQ Client installed and up to date (since it is free) wherever you run this Java code and it should point to those jar files and when you update the client, your code will get that update.
Never package WMQ jars with your code.
_________________
Joseph
Administrator - IBM WebSphere MQ (WMQ) V6.0, IBM WebSphere Message Broker (WMB) V6.1 & V6.0
Solution Designer - WMQ V6.0
Solution Developer - WMB V6.1 & V6.0, WMQ V5.3 |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Mar 28, 2008 11:20 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| venusboy wrote: |
I understand why it cannot write to the DLQ (authority issues), but this means that the IBM JMS implemention is performing the deadletter put.
|
This post is regarding the back out queue (the responsibility of the app as indicated above) not the DLQ (used by the qmgr and always has been).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| venusboy |
| Posted: Fri Mar 28, 2008 11:29 am Post subject: |
|
|
Acolyte
Joined: 11 Jun 2002
Posts: 51
|
Yes you are quite right, I fully understand why it failed to be put to the dead-letter queue, but thats the point as I never thought that without explity coding backout/DLQ features within my code it would use the DLQ.
Now we have moved to v6 it seems that the JMS is using the backout queue, therefore this is quite a major change for us. I did not see anything in IBMs release notes about this (but I must have missed it). |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Mar 28, 2008 11:36 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| venusboy wrote: |
| Yes you are quite right, I fully understand why it failed to be put to the dead-letter queue, but thats the point as I never thought that without explity coding backout/DLQ features within my code it would use the DLQ. |
No it wouldn't. The DLQ is exclusively for undeliverable messages. If your message has been delivered for your application to read, then it won't go to the DLQ ever.
| venusboy wrote: |
| Now we have moved to v6 it seems that the JMS is using the backout queue, therefore this is quite a major change for us. I did not see anything in IBMs release notes about this (but I must have missed it). |
It's always been the case that Java apps running under an app server will honour the backout queue. This is a function of the server, not WMQ or the JMS implementation.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
