| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| problem in getting first message off queue using MQI Java |
« View previous topic :: View next topic » |
| Author |
Message
|
| aks |
 Posted: Sat Sep 11, 2004 5:30 pm Post subject: problem in getting first message off queue using MQI Java |
 |
|
Voyager
Joined: 19 Jul 2002
Posts: 84
|
I have a Java application that runs as an NT service and listens on a queue using an MQGET with a long wait and then spawns a thread to process the message when it arrives.
I see sometimes that when a message is put on the queue, the queue.get does not always appear to get the first message off the queue when the service is first started (ie no log statements to indicate that message has been retrieved and no activity for processing the message), even though the queue is empty as reported by the RFHUTIL app. When a 2nd message arrives, then it starts getting messages from then on without fail.
It does not happen all the time, so is there some delay when the services starts during which connection to the queue manager is established and other initialisation activity that would cause this problem?
The java code which does the get is similar to this:
MQGetMessageOptions gmo = new MQGetMessageOptions();
gmo.matchOptions = MQC.MQMO_NONE;
gmo.options = MQC.MQGMO_FAIL_IF_QUIESCING | MQC.MQGMO_WAIT;
MQMessage mqMessage = new MQMessage();
queue.get(mqMessage, gmo);
Any help would be appreciated
Thanks
Alan |
|
| Back to top |
|
 |
| PeterPotkay |
| Posted: Sun Sep 12, 2004 4:14 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Quote: |
I see sometimes that when a message is put on the queue.....even though the queue is empty as reported by the RFHUTIL app.
|
So is there a message there or not?
If the RFHUTL app reports no message, why would your program see it?
If the depth is > 0, and both programs retrieve nothing, the message could have expired, or it might be on the queue uncommited, meaning the depth shows but it is not retrievable.
The second message is not expired and/or committed, so your app retrieves it.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| aks |
| Posted: Sun Sep 12, 2004 2:41 pm Post subject: |
|
|
Voyager
Joined: 19 Jul 2002
Posts: 84
|
Well,
my logs say that the MQGET did not fire, but RFHUTIL does not show a message either. But your suggestion that the message was not committed may be a cause.
I added MQC.MQPMO_SYNCPOINT flag to the put message options and did a qm.commit() after the put - the problem still occurs, but not as often (1 in 10 times after a restart)
The documentation seems to indicate that the above PMO flag is required for the committ() to work. Is this true?
My problem is similar to what's in this thread: http://www.mqseries.net/phpBB2/viewtopic.php?t=16493&highlight=commit
Thanks
Alan |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Sep 13, 2004 5:00 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
You got the cart in front of the horse? You are issuing syncpoint on the put only because you are commiting the QM? If all you are doing in the sending app is putting an MQ message, and there will never be a reason to rollback that put, do the put with no syncpoint, and get rid of the commit call to the QM.
Try it this way for a while to see if it works.
Do you have all the MQ actions wrapped inside a try/catch? Maybe some of your puts are failing, and that is why they don't make it to the queue. Or maybe some of the commits are failing.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| aks |
| Posted: Mon Sep 13, 2004 1:56 pm Post subject: |
|
|
Voyager
Joined: 19 Jul 2002
Posts: 84
|
| Quote: |
| You are issuing syncpoint on the put only because you are commiting the QM? If all you are doing in the sending app is putting an MQ message, and there will never be a reason to rollback that put, do the put with no syncpoint, and get rid of the commit call to the QM. |
I agree. Having no syncpoint and no commit is the way I have always done it. But I was willing to try committing if there was an increased chance of the message actually getting on the queue in a committed state.
I trap all MQExceptions and IOExceptions thrown by the various MQ methods and there seems nothing wrong.
This problem has got me really frustrated.
Alan |
|
| 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
|
|
|
|
