| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Getting 2033 Error whereas the queue is not empty |
« View previous topic :: View next topic » |
| Author |
Message
|
| AC12 |
 Posted: Thu May 17, 2007 7:53 am Post subject: Getting 2033 Error whereas the queue is not empty |
 |
|
Newbie
Joined: 17 May 2007
Posts: 2
|
Hi All,
I have been doing some seach on posted topics here about 2033 error (MQRC_NO_MSG_AVAILABLE). My interest is to discuss with members having hit the same and recurrent error code whereas the queue is not empty (this is visible through other MQ command line tools). The problem manifests itself in the client suddenly. We keep getting the messages and all of sudden we hit 2033 error although there are lots of messages waiting in the queue.
The MQ client program is a java one and the logic to browse/get the messages is implemented within a loop.
- The queue is accessed with the following options:
MQOO_INPUT_AS_Q_DEF|MQOO_BROWSE
- The wait interval is set to 5 seconds and the option used to browse of messages:
MQGMO_WAIT|MQGMO_BROWSE_NEXT|MQGMO_LOCK
- and the actual get of the messages destructively has the following options:
MQGMO_NO_WAIT|MQGMO_MSG_UNDER_CURSOR
The client is connected to a local queue feeded by a remote one. According to people in charge of exploiting the application, there are lots of messages waiting to be consumed and the client is not catching them since the Java API is returning the error code 2033. Moreover the message put in the queue are committed.
Notes: There is no selection criteria on the messages to be consumed. We take any message found in the queue.
The only way to get the client program getting the messages again is to close the queue, drop the connection (disconnect the manager) and do the access again through a new created manager.
The questions here:
- Have you already encountered such situation and what was the cause and the way to resolve it ?
- Is there any missing topic in the code ?
Thanx.
AC.
Last edited by AC12 on Fri May 18, 2007 9:05 am; edited 2 times in total |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu May 17, 2007 1:44 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
First point - why the browse? What's the point / requirement? It adds no value that I can see to your code. You browse the 1st message, lock it then read it destructively. This is exactly what happens if you simply do a destructive read.
There are a couple of options. The messages could be on the queue, yet uncommitted by the putting application. They would show up in the queue depth, yet could not be read off. It's a bit unlikely given the solution being disconnect / reconnect but it could be ending the transactions.
More likely, the locking mechanism or cursor is getting confused and when you try to read the mechanism you get a false 2033. You don't say what version of MQ you're using, but v5.3 pre-CSD 10 had some very interesting features in it's Java support!
Suggestions:
- ditch the browse unless you have very, very compeling reasons to use it
- if you're using Java on v.5.3, make sure you're on the latest CSD (12? 13?)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu May 17, 2007 5:40 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
The questions here:
- Have you already encountered such situation and what was the cause and the way to resolve it ? |
Looks like you are not clearing the message when looking for the next message.
Before doing the next get you must clear (set to MQCI_NONE) the msgId and CorrelId on the MQMD being passed to the get.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| AC12 |
| Posted: Fri May 18, 2007 8:49 am Post subject: |
|
|
Newbie
Joined: 17 May 2007
Posts: 2
|
Thanks both for your posts.
My responses are inline:
| Quote: |
First point - why the browse? What's the point / requirement? It adds no value that I can see to your code. You browse the 1st message, lock it then read it destructively. This is exactly what happens if you simply do a destructive read.
|
The message being browsed/locked can be rejected if the parsing of the content fails. In this case it is kept in the queue and not removed. If the parsing succeeds we do another get to remove it from the queue. This is the main reason of dealing that way with the messages.
| Quote: |
There are a couple of options. The messages could be on the queue, yet uncommitted by the putting application. They would show up in the queue depth, yet could not be read off. It's a bit unlikely given the solution being disconnect / reconnect but it could be ending the transactions.
|
This could be a reason. However, the "putting" guys state that the messages are committed. The only way to recover from this situation and be able to see the messages is to disconnect/re-connect
| Quote: |
- if you're using Java on v.5.3, make sure you're on the latest CSD (12? 13?)
|
Sorry, I did not mention the version. It's against MQ 5.3. I do not know which level of patches are applied on the deployed instance of MQ.
| Quote: |
Looks like you are not clearing the message when looking for the next message.
|
The message is "cleared" before each get (method clearMessage() is being called.
| Quote: |
Before doing the next get you must clear (set to MQCI_NONE) the msgId and CorrelId on the MQMD being passed to the get.
|
This was my 1st suspicion after reading thousands of lines from the MQ docs and posted messages here. Those options are not used. Only the clearMessage() is invoked on the MQMessage instance.
This should be something like:
| Code: |
myMessage.correlationId = MQC.MQCI_NONE;
myMessage.messageId = MQC.MQMI_NONE;
|
I will give it a try and see if it makes the trick
Keep you posted.
Tnx.
_____
AC. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri May 18, 2007 5:24 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
| The message being browsed/locked can be rejected if the parsing of the content fails. In this case it is kept in the queue and not removed. If the parsing succeeds we do another get to remove it from the queue. This is the main reason of dealing that way with the messages. |
This is entirely going the wrong way about it.
Read up in the programing manual on SYNCPOINT.
You do a destructive read with the syncpoint option, process, if there is a problem you can then rollback or put the message to a backout queue and commit.
| Quote: |
| The message is "cleared" before each get (method clearMessage() is being called. |
As you suspected this is entirely not enough. It does clear the content but the MQMD retains its values and the next get is being done with messageId and correlId matching which you did not want to do.....
| Quote: |
| fjb_saper wrote: |
Before doing the next get you must clear (set to MQCI_NONE) the msgId and CorrelId on the MQMD being passed to the get.
|
This was my 1st suspicion after reading thousands of lines from the MQ docs and posted messages here. Those options are not used. Only the clearMessage() is invoked on the MQMessage instance.
This should be something like:
| Code: |
myMessage.correlationId = MQC.MQCI_NONE;
myMessage.messageId = MQC.MQMI_NONE;
|
I will give it a try and see if it makes the trick
Keep you posted.
Tnx.
_____
AC. |
This should work for you...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Sat May 19, 2007 7:08 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| AC12 wrote: |
| The message being browsed/locked can be rejected if the parsing of the content fails. |
Do not do this. It's far more efficient to read and roll back than to browse.
Your actual problem is likely to be the id's not being cleared as fjb_saper suggests.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| 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
|
|
|
|
