| Author |
Message
|
| saurav |
 Posted: Mon Dec 05, 2005 12:47 pm Post subject: MQRC_NO_MSG_AVAILABLE even when there are messages on MQ. |
 |
|
Newbie
Joined: 28 Oct 2005
Posts: 5
|
Hi All,
We are facing an issue while reading messages from an Windows MQ Server v5.3 (CSD09). A third party software writes to the Queue REQUEST.Q, we can see the message (using the MQ explorer) in the REQUEST.Q on the MQ server but our service is unable to read it.
We first try to browse the message and only if a message is available, it is read by our application (C program). The only options set for MQGET API for browsing are MQGMO_BROWSE_NEXT and the MsgId and CorrelId are set to MQMI_NONE and MQCI_NONE respectively. The MQGET API returns a failure with reason code as MQRC_NO_MSG_AVAILABLE.
A different test executable of ours uses the same functions (code) to browse and read the messages from an MQ. This test executable is able to read the message from the REQUEST.Q.
If i put the same messages (same format) as that put by the third party software to the REQUEST.Q using a test executable, our application is able to read the message based on FIFO order.
As an example if the REQUEST.Q has 'm' number of messages written by the third party application ( we can see these messages on the REQUEST.Q using the browser but our application can not browse or read them ) and we use our test executable to write 'n' similar messages to the REQUEST.Q, then 'n' messages are read by our application from the REQUEST.Q. Finally after the application reads 'n' messages the number of messages remaining on the REQUEST.Q is 'm -n'.
If we clear all the messages from the REQUEST.Q and use our test executable to write message to the REQUEST.Q, all messages written to the REQUEST.Q are processed by our service.
I was going through the IBM website and found a link mentioning a issue similar to the problem we are facing
( http://www-1.ibm.com/support/docview.wss?uid=swg1IY48070 ).
Is there any MQ parameter that we need to look into?
Some documentation on the IBM support site and MQSeries.net suggested that such a case happens when the application writes to the Queue with out committing the data. How can we check this ?
Regards,
Saurav. |
|
| Back to top |
|
 |
| kevinf2349 |
| Posted: Mon Dec 05, 2005 8:58 pm Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Maybe the 3rd party software isn't commiting the messages? |
|
| Back to top |
|
|
| saurav |
| Posted: Tue Dec 06, 2005 9:17 am Post subject: |
|
|
Newbie
Joined: 28 Oct 2005
Posts: 5
|
The function used by the application and the test executable to browse messages from the REQUEST.Q on the MQ server is the same (exactly the same code).
Please look at the example i gave in the earlier post. The application is able to read the messages written by the third party software provided we write some messages to the REQUEST.Q using our test executable.
How can one explain the case mentioned in the example in my previous post? |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Dec 06, 2005 9:33 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
There isn't anything about MQ that would explain this.
What is the open input count on the queue when the application can't read messages?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| saurav |
| Posted: Tue Dec 06, 2005 10:58 am Post subject: |
|
|
Newbie
Joined: 28 Oct 2005
Posts: 5
|
The Open Input Count for the REQUEST.Q is 1 when there are messages on the queue that the application is unable to read.
Even when there are no messages on the REQUEST.Q the value of Open Input Count is 1.
When i use the test executable to read messages from the REQUEST.Q (the messages that the application is unable to read) the value of the Open Input Count for REQUEST.Q equals 2 as long as the test executable is running. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Dec 06, 2005 11:05 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
So the receiving application has the queue open and is trying to get messages, or could be trying to get messages.
It could also be stuck in a loop or something on the first message on the queue, or it could be stuck in a loop on something else.
I think you need to open a problem ticket with the third party application provider and ask them for help.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| saurav |
| Posted: Tue Dec 06, 2005 11:33 am Post subject: |
|
|
Newbie
Joined: 28 Oct 2005
Posts: 5
|
I would have thought the same except that the application is up and running from the last 3 days and till date i have used the test executable to write about 500 requests to the REQUEST.Q and each of those requests have been processed instantaneously.
eg.
3rd party software writes 10 messages to the REQUEST.Q -> None of the requests are read. REQUEST.Q has 10 messages.
Test executable writes 5 messages to REQUEST.Q -> 5 messages are read by the application instantaneously (messages are read based on FIFO, messages written by the 3rd party software are read first). The REQUEST.Q has 10 messages.
Test executable writes 500 messages to REQUEST.Q -> 500 messages are read by the application instantaneously. The REQUEST.Q has 10 messages.
A test executable reads all the messages from the REQUEST.Q so there are no messages on the REQUEST.Q
Test executable writes 500 messages to REQUEST.Q -> All 500 messages are read by the application instantaneously. The REQUEST.Q has no messages. |
|
| Back to top |
|
|
|
|
