| Author |
Message
|
| John W |
 Posted: Tue Feb 28, 2006 9:37 am Post subject: Too many MQGET_REPLY 2033 messages are replied. |
 |
|
Newbie
Joined: 27 Feb 2006
Posts: 3
|
Hello there,
We currently have two web applications that implement standard JMS APIs. Both apps are deployed on websphere 5.1 which has WMQ client installed. The WMQ client in turn connects to a queue manager (created on a WMQ 5.3 server) that runs on a separate node from the WAS node. In the app servlet init() methods, we make JMS connections to the queue provider, including temporary queues and one permanent queue. The connection seems to work fine since we are definitely getting messages through from one app to the other. However, such message flow could sometimes take 10 to 20 seconds.
We tried ethereal to do packet sniff on the WMQ server node. The initial connection message flow shows nothing unusual. I am listing part of the flow here:
INITIAL_DATA
INITIAL_DATA: CHL=SYSTEM.DEF.SVRCONN QM=MY_QMGR
USERID_DATA
MQCONN: App=Websphere QM=MY_QMGR
MQCONN_REPLY
MQINQ
MQINQ_REPLY
MQOPEN Obj=MY_QUEUE
MQOPEN_REPLY Obj=MY_QUEUE
MQINQ
MQINQ_REPLY
MQINQ
MQINQ_REPLY
INITIAL_DATA
INITIAL_DATA
INITIAL_DATA
INITIAL_DATA: CHL=SYSTEM.DEF.SVRCONN QM=MY_QMGR
...
After the initial message flow completes in a few seconds, we start to see the following message pair to repeat in every other 10ms or so and the flow goes forever.
MQGET
MQGET_REPLY [RC=2033]
MQGET
MQGET_REPLY [RC=2033]
MQGET
MQGET_REPLY [RC=2033]
...
We figured this ever-going flow is the root cause why the app message flow is being delayed. We would like to know what is causing such infinite MQGET and MQGET_REPLY flow. Any direction to solving this issue or help would be greatly appreciated.
Thanks a lot. |
|
| Back to top |
|
 |
| mvic |
| Posted: Tue Feb 28, 2006 9:43 am Post subject: Re: Too many MQGET_REPLY 2033 messages are replied. |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| What code levels please (fixpacks, CSDs etc.)? Both WAS and WMQ code levels will help in fully describing the system. |
|
| Back to top |
|
|
| John W |
| Posted: Tue Feb 28, 2006 10:08 am Post subject: |
|
|
Newbie
Joined: 27 Feb 2006
Posts: 3
|
| Thanks for the quick reply. The WAS is 5116 and WMQ is 5.3 CSD01. |
|
| Back to top |
|
|
| mvic |
| Posted: Tue Feb 28, 2006 12:42 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| John W wrote: |
| Thanks for the quick reply. The WAS is 5116 and WMQ is 5.3 CSD01. |
I'm not sure about the WAS level, but the WMQ is very downlevel. That code (if memory serves) was released in October 2002. There have been a LOT of fixes for problems reported by customers in that time. The current maintenance is CSD12, which appears to be a good one, as far as we can tell so far.
I would strongly recommend you upgrade to CSD12 if at all possible. |
|
| Back to top |
|
|
| vennela |
| Posted: Wed Mar 01, 2006 12:06 am Post subject: |
|
|
Jedi Knight
Joined: 11 Aug 2002
Posts: 4055
Location: Hyderabad, India
|
First of all I don't see anything wrong with you getting 2033s
All it is saying is there are no messages available, because the app is polling for messages.
What is that you are trying to achieve?
| Quote: |
| Why are you asking on here? It is your app that is doing it! |
The suggestion is to upgrade the maintenance level to make your life easier. |
|
| Back to top |
|
|
| John W |
| Posted: Wed Mar 01, 2006 4:56 am Post subject: |
|
|
Newbie
Joined: 27 Feb 2006
Posts: 3
|
| After CSD12 has been updated on WMQ server, it does not seem to make any difference. We are still getting the infinite message flow. The message description in the packet shows blank for both queue and queue manager properties. As far as JMS coding goes in the applications, we basically send message through a permanent queue and create temporary dynamic queues for the replies. Nothing fancy! |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Mar 01, 2006 5:07 am Post subject: Re: Too many MQGET_REPLY 2033 messages are replied. |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| John W wrote: |
| We figured this ever-going flow is the root cause why the app message flow is being delayed. We would like to know what is causing such infinite MQGET and MQGET_REPLY flow. Any direction to solving this issue or help would be greatly appreciated. |
Okay, this is not likely the root cause of the problem. The infinite loop you are seeing is simply how the application is written. Now, it could be a contributer to the problem, that it is looping so fast - typically one would code the GET to include a wait time. Then it will sit and wait for the next message , and return immediately when the message is available.
So it's somewhat inefficient, but it's not the cause of your problem likely. How are you measuring that sometimes the message takes 10 to 20 seconds? What steps count in that time - from the send on one side to the receipt on the other, or is application processing counted? Are messages being put using syncpoint? If so, is there a delay between when they are put and when the put is committed?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| docbill |
| Posted: Wed Mar 01, 2006 7:39 am Post subject: Re: Too many MQGET_REPLY 2033 messages are replied. |
|
|
Newbie
Joined: 01 Mar 2006
Posts: 2
|
| jefflowrey wrote: |
Okay, this is not likely the root cause of the problem. The infinite loop you are seeing is simply how the application is written. Now, it could be a contributer to the problem, that it is looping so fast - typically one would code the GET to include a wait time. Then it will sit and wait for the next message , and return immediately when the message is available.
|
I find this reference to "GET" confusing. A standard J2EE application does not call "MQ GET" directly. I expect this is called indirectly via the QueueConnection.
The application calls "MessageConsumer.receive". Depending on which part of the code it calls one of:
MessageConsumer.receive(50L)
MessageConsumer.receive(30000L)
MessageConsumer.receiveNoWait()
However, we did a small test servlette that only used:
MessageConsemer.receive(30000L)
on both a permanent and temporary queue.
We received hundreds of 2033 even with this test servlette.
Not surprising, since QueueConnection should be looping in the background to poll the MQ Queue with a timing that is indepentant of what we specify with the receive call. Otherwise receiveNoWait() would NEVER work.
Bill |
|
| Back to top |
|
|
| mvic |
| Posted: Wed Mar 01, 2006 9:03 am Post subject: Re: Too many MQGET_REPLY 2033 messages are replied. |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
docbill, are you working with John W?
How often are the MQGET calls being made inside your MessageConsumer.receive(30000L) call? And are you sure this is the only MessageConsumer in the system that's active at the time?
John W, if you are just calling MessageConsumer.receive(30000L) or something similar I would not expect MQGET calls separated by 10 ms. This sounds like a problem worth reporting.
If, on the other hand, the call is MessageConsumer.receive(10) then remember the 10 is milliseconds not seconds.
(Also, check whether you're using MQConnectionFactory.setPollingInterval() or the equivalent JMSAdmin property POLLINGINT. Again note the units taken for the polling interval is milliseconds).
EDIT: fix typos
Last edited by mvic on Wed Mar 01, 2006 6:26 pm; edited 1 time in total |
|
| Back to top |
|
|
| docbill |
| Posted: Wed Mar 01, 2006 11:13 am Post subject: |
|
|
Newbie
Joined: 01 Mar 2006
Posts: 2
|
Yes John and I are referring to the same application.
I was mistaken. Even the simple application I wrote for testing was not doing just receive(30000L). Like the real application one of the threads it was looping:
void Message getMessage() {
Message retval=null;
do {
retval=consumer.receiveNoWait();
if(retval != null) break;
retval=tempConsumer.receive(50L);
} while(retval == null);
return retval;
}
Each receive call does seem to correspond to one 2033 message. I changed this test simply to do:
void Message getMessage() {
Message retval=null;
do {
retval=consumer.receive(30000L);
} while(retval == null);
return retval;
}
With the MQ configuration John described no messages were received. (The build worked flawlessly on Sun MQ...)
I then reduced the time to 500L, and message were received quickly perminent queue.
So it seems receive isn't working on perminent queues if the receive time is greater than some threshhold value.
I then tried the same test with a temporary Queue. For wait times of 30000 and 500 ms no messages were received. But for a wait time of 50 ms the messages were received after about 4 seconds.
So it looks like the 2033 messages are simply 1 per receive not a problem. The real problem of messages on the temporary qeue only being delivered when we poll very frequently and taking a long time to deliver still exist.
Bill |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Mar 01, 2006 12:08 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
That I don't quite get.
The wait intervall has nothing to do with whether the message is going to be delivered or not.
a) a message is on the queue in a gettable state (important)
receiveNoWait() will give you the message,
receive(10L) will give you the message,
receive(10000L) will give you the message,
receive(100000L) will give you the message.
b) if you are talking about a request response scenario be aware of following:
1) you will only get a response from the server application if you did commit the request and the server committed the response...
2) It will take some time for the message to go through the network and for the serving app to reply. MQ is not responsible for this amount of time but the requester will still have to deal with it.
3) the time is expressed in milliseconds, so 500 is half a second !
4) You need to find out what the average response time is and check whether it is acceptable to your application. Start with something outrageous like 100000L or one hundred seconds and have your app log the time difference from before and after the receive....
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
