| Author |
Message
|
| rajesh_sk |
 Posted: Wed Jul 02, 2008 5:44 am Post subject: 2033 error-though there are messages(commited) in the queue |
 |
|
Newbie
Joined: 02 Jul 2008
Posts: 7
|
Hi Guys,
I have a typical scenario where in there are messages in the queue but I am getting a 2033 when I try to get a message.
I am aware of the following points and have taken care that this did not happen:
1) 2033 does not mean no messages in queue but no matches found with your requirement (selective get based on message id or correlation id)
2) 2033 can occur when we try to get a uncomitted message.
I have ensured that I am not doing any of the above things. I am using MQ native API's to connect to QM and get messages.
The worst part is that I get this 2033 only ocassionally but not regularly.
Can any one throw some light on the other scenarios in which this can occur? |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Wed Jul 02, 2008 1:21 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
The messages are not in a gettable state.
Get from another thread...
Get under syncpoint from another thread followed by a rollback...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| rajesh_sk |
| Posted: Thu Jul 03, 2008 2:12 am Post subject: |
|
|
Newbie
Joined: 02 Jul 2008
Posts: 7
|
Thanks for the reply.
We have two Java applications.
Application A puts the message and Application B gets this message.
As I had mentioned earlier, A is operating the queue in transaction mode (I mean it is using sync point in openoptions) and it has comitted the message after placing it in the queue.
Application B is also operating in transaction mode (sync point in open options). But B is not able to get the message.
Can you elaborate on the point 'thread followed by a rollback... '. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jul 03, 2008 10:38 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
How many instances of A / B do you have running?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| rajesh_sk |
| Posted: Thu Jul 03, 2008 11:08 pm Post subject: |
|
|
Newbie
Joined: 02 Jul 2008
Posts: 7
|
| Once instance of A and once instance of B. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Jul 04, 2008 7:26 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| rajesh_sk wrote: |
| Once instance of A and once instance of B. |
Do they share a connection or each have their own connection?
They should each have their own connection.
And check the ipprocs. If you have more than 1 you are in contention with some other process. Displaying the connections on the object might help.
How are you handling a "poison" message?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| rajesh_sk |
| Posted: Sun Jul 06, 2008 7:46 pm Post subject: |
|
|
Newbie
Joined: 02 Jul 2008
Posts: 7
|
Both the applications have their own set of connections. They do not share any connections. They run on different JVMs.
In case of a poison message we are moving it into a back out queue(at application level). But the problem is that we have not even got the message so we cannot decide if it is a poison message or a normal message.
I have even checked the IP Procs and the count was zero at that time.
What I could not understand is that we are able to get the same message when we try after some time (with the same application).
Details of the App which tries to get the message:
1) It opens the queue with appropriate open options.
2) Checks the depth of the queue.
3) If the depth is greater than zero, it tries to issue a get call, if not sleeps for some time and then checks for some more messages.
The problem was the depth of the queue is returned as 10 but when application issued a get call it did not receive any message. As I have mentioned earlier,all the messages were comitted and we were not doing selective get operation as well.
The version of com.ibm.mq.jar that I am using is '6.0.0.0 - j000-L050519.1'. Is there any other latest version available after this? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Jul 07, 2008 7:12 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| rajesh_sk wrote: |
Details of the App which tries to get the message:
1) It opens the queue with appropriate open options.
2) Checks the depth of the queue.
3) If the depth is greater than zero, it tries to issue a get call, if not sleeps for some time and then checks for some more messages.
The problem was the depth of the queue is returned as 10 but when application issued a get call it did not receive any message. As I have mentioned earlier,all the messages were comitted and we were not doing selective get operation as well.
The version of com.ibm.mq.jar that I am using is '6.0.0.0 - j000-L050519.1'. Is there any other latest version available after this? |
Checking queue depth has been discussed on this forum and is bad practice. You will have a qdepth even though messages are not in a gettable state.
What you should do:
open queue check RC
error handling
Do while RC <> 2033
get message
if RC <> 2033 process message
endwhile
close queue.
Also do not make your application sleep. Do a get with wait(time) (Don't use illimited unless you plan to specify how you close the app (end message required...))
Latest versions are 6.0.2.4 or 7.0
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqmaniac |
| Posted: Mon Jul 07, 2008 7:19 am Post subject: |
|
|
Master
Joined: 27 Dec 2005
Posts: 201
|
Looks Lik a message Expiry propblem..
Can you check if the Message Expiry is SET ?
we had this but resolved when we set the expiry to "-1" |
|
| Back to top |
|
|
| rajesh_sk |
| Posted: Wed Jul 09, 2008 8:04 pm Post subject: |
|
|
Newbie
Joined: 02 Jul 2008
Posts: 7
|
The application is already developed and we cannot change the design at this point but yes what you have said is absolutely correct. In the application we provide many options to get a message from the application - with wait time and with out wait time, selective get , normal get etc.
Version 7.0 is a beta version, can you give me the location where I can download the 6.0.2.4 version (com.ibm.mq.jar).
We are setting expiry time as -1 for the messages.
This cannot be a problem with the expiry because if there are expired messsages in the queue, the queue gets cleared when we try to get the message. But in my case the depth was still 10 even after thea application tried to get the message. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Jul 10, 2008 1:21 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
The client is in the support packs... There should be a link on the top of the page.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| sridhsri |
| Posted: Thu Jul 10, 2008 8:43 pm Post subject: |
|
|
Master
Joined: 19 Jun 2008
Posts: 297
|
| I don't think you can download just one jar file. I suggest you download MQ Client. I think that will have the jar file you are looking for. |
|
| Back to top |
|
|
| rajesh_sk |
| Posted: Tue Jul 15, 2008 9:23 pm Post subject: |
|
|
Newbie
Joined: 02 Jul 2008
Posts: 7
|
Hi fjb_saper,
Can you please eloborate on 'You will have a qdepth even though messages are not in a gettable state.'. When will the messages be in un-gettable state? |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Jul 16, 2008 5:39 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Expired messages
Locked messages
Uncommitted messages
The topic of why you should never use q depth for getting messages has been discussed lots of times here.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| rajesh_sk |
| Posted: Wed Jul 16, 2008 9:26 pm Post subject: |
|
|
Newbie
Joined: 02 Jul 2008
Posts: 7
|
Thanks for the reply.
I am aware of the reasons why we should not use depth for getting messages.
My questions was why am I not able to get a message when I can browse it from the queue using MQExplorer.
By the way what are these Locked messages? |
|
| Back to top |
|
|
|
|
