| Author |
Message
|
| deeps1281 |
 Posted: Mon Dec 26, 2011 3:38 am Post subject: Inconsistency in polling queue for message |
 |
|
Apprentice
Joined: 31 Aug 2005
Posts: 29
|
Hi,
We have an issue on our production ,where a compute node drops a message in a MQ queue,from where a java code reads the queue using MQ Java api.
We have seen recent inconsistencies where sometimes after the compute node puts the message,the MQ java api does not find the message in the queue or at times gets the message after multiple retries.Just to do some debugging,we had a script running to poll the queue for its depth using the DISPLAY CURRDEPTH command.At the times where the java api can not poll the queue,at those times even the CURRDEPTH command does not give any output.I have checked the queue properties and does not look like a problem there.Since it is not a consistent issue,I am also not able to replicate it on a test environment.
Any help will be appreciated. |
|
| Back to top |
|
 |
| vennela |
| Posted: Mon Dec 26, 2011 6:23 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
Looks like this is a case of poison message
Your java program is trying to get the message and process it, but it cannot process the message and is putting it back on the queue. In this case, if the message is under a UOW, CURDEPTH also will not show the correct number.
There might be another angle too. The flow itself is not putting the message.
In order to correctly troubleshoot it, try to PUT disable it and see if there are any errors in the broker. Another test case would be to GET disbale the queue and see if the java program fails.
Keep working along those lines |
|
| Back to top |
|
|
| zpat |
| Posted: Mon Dec 26, 2011 8:39 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| Don't poll queues. MQ is best event driven. If you want to wait for a message to arrive use the MQGET option MQGMO_WAIT (or its JMS version). |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Dec 26, 2011 9:57 am Post subject: Re: Inconsistency in polling queue for message |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| deeps1281 wrote: |
Just to do some debugging,we had a script running to poll the queue for its depth using the DISPLAY CURRDEPTH command.At the times where the java api can not poll the queue,at those times even the CURRDEPTH command does not give any output.I have checked the queue properties and does not look like a problem there.Since it is not a consistent issue,I am also not able to replicate it on a test environment.
Any help will be appreciated. |
And remember that queue depth is not an accurate measure for what you had in mind there... Messages that are not accessible still count for queue depth...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Dec 26, 2011 2:42 pm Post subject: Re: Inconsistency in polling queue for message |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| deeps1281 wrote: |
| We have seen recent inconsistencies where sometimes after the compute node puts the message,the MQ java api does not find the message in the queue or at times gets the message after multiple retries. |
How have you verified that the transactionality of the flow is correct? Are the multiple retries successful always after the flow has finished?
How is the Java thing triggered? Is it actually triggered in the WMQ sense, is it checking CURRDEPTH or is it a long-running app with a constant wait on the queue?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| deeps1281 |
| Posted: Tue Dec 27, 2011 2:42 am Post subject: |
|
|
Apprentice
Joined: 31 Aug 2005
Posts: 29
|
Thanks for the replies. A quick summary of the entire flow
The Java program(acts as an adapter) is trigerred when it recieves a payload from a non MQ application over a socket and then it places the input queue of the compute node flow.The flow validates the message for some rules and then places the response in another queue,on which the java program is polling for a response.After that the flow propagates the message for further processing.
The problem is coming when the flow drops the response message in the queue,but the java adapter says no message found.I am assuming the transactionality of the flow is correct since it is not throwing any error while putting the message in the response queue and then proceeds forward to successfully drop the message.
Since this is a production environment and its an inconsistent error,I am unable to replicate it or try things like PUT disable.
Are there any logs in the queuemanager which confirm the PUT in the queue was successful? |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Dec 27, 2011 6:41 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| deeps1281 wrote: |
| I am assuming the transactionality of the flow is correct since it is not throwing any error while putting the message in the response queue and then proceeds forward to successfully drop the message. |
Flawed assumption.
| deeps1281 wrote: |
| Are there any logs in the queuemanager which confirm the PUT in the queue was successful? |
Nothing in the queue manager records this, but passes a reason code back to the putting application. The MQOutput node will trap this and provided your flow is correctly coded this will then be handled.
If your flow just assumes it's working then that could be your problem.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Dec 27, 2011 1:00 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Also, if you want your java application to be able to read the response before flow completion, you better make sure that your MQOutput node for returning the response is not transacted..., otherwise the response is only available at the end of the flow.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
