| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| WMQ 5.3: onMessage() for 2nd queue is delayed |
« View previous topic :: View next topic » |
| Author |
Message
|
| mqsnbmp1 |
 Posted: Tue Feb 28, 2006 8:34 am Post subject: WMQ 5.3: onMessage() for 2nd queue is delayed |
 |
|
Apprentice
Joined: 18 Oct 2005
Posts: 25
|
Hi,
I have a simple scenario (WMQ 5.3, JMS API only). One Java app writes into 2 different JMS queues. Another Java app reads from these queues (Text Messages). If messages are written by the sending app into the 1st queue (the one that was used to create the 1st receiver for the session in receiving app), it is read instantly by receiving app. However, messages written to the 2nd queue (the one that was used to create the 2nd receiver for the same session) take anywhere from 0.5 to 5 sec. This behavior is not queue-specific, because if I swap queue names in configuration, it is always the 1st queue that is fast, and the 2nd queue that is slow. It almost looks like some kind of TCP_NODELAY-related setting, or a limitaion on how many receiving channels can be handled per one asynchronous session. I tried the same scenarion against ActiveMQ, and both queues performed instantly. Any insight would be appreciated.
Thanks. |
|
| Back to top |
|
 |
| mvic |
| Posted: Tue Feb 28, 2006 9:30 am Post subject: Re: WMQ 5.3: onMessage() for 2nd queue is delayed |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| mqsnbmp1 wrote: |
| If messages are written by the sending app into the 1st queue (the one that was used to create the 1st receiver for the session in receiving app), it is read instantly by receiving app. However, messages written to the 2nd queue (the one that was used to create the 2nd receiver for the same session) take anywhere from 0.5 to 5 sec. |
Is it possible to create a second Session? It may not be possible, but...
In the case where one Session has onMessage listeners registered for more than one queue, there is an amount of round-robin looping that must be done in the client. When the queues are empty, a special case arises. MQ's JMS classes have to go into a get-with-wait on one of these queues, in order to avoid loading the network with polling requests on the queue manager. The get-with-wait has a timeout, as you've seen, and then queue 2 gets polled.
If it's possible to have 2 Sessions, and have a single onMessage listener for each Session, then you should not see this problem. MQ's JMS classes should start a new thread to serve the 2nd Session, and then the listeners for the 2 queues will be independent, such that you should no longer see a delay.
Hope this helps. |
|
| Back to top |
|
|
| mqsnbmp1 |
| Posted: Tue Feb 28, 2006 10:35 am Post subject: |
|
|
Apprentice
Joined: 18 Oct 2005
Posts: 25
|
| Thanks, this actually explains it all. It seems odd though, because within a session message delivery is not really asynchronous, but rather a combination a synchronous receiving with timeouts and polling. |
|
| Back to top |
|
|
| mvic |
| Posted: Tue Feb 28, 2006 12:48 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| mqsnbmp1 wrote: |
| Thanks, this actually explains it all. It seems odd though, because within a session message delivery is not really asynchronous, but rather a combination a synchronous receiving with timeouts and polling. |
It's a limitation in the current design of MQ's JMS. Internally we have to go into a get-with-wait on one of the queues, because we can't do a get-with-wait on more than one queue at once. If it just happens that the "other" queue receives a message first, this goes un-noticed until the get-with-wait times out.
Is it possible for you to use a 2nd Session in order to decouple the operations on the two queues? I realise this may require a fair bit of extra coding - but not too much perhaps? |
|
| Back to top |
|
|
| mqsnbmp1 |
| Posted: Tue Feb 28, 2006 1:14 pm Post subject: |
|
|
Apprentice
Joined: 18 Oct 2005
Posts: 25
|
I just modified the program to create a separate session for each receiving queue, and it solved the delay problem. I really appreciate your insight into this issue.
I have a follow up question -- how much overhead is in creating separate sessions for each receiver (except that it creates an additional thread, which is fine). Also, is there any harm in creating separate sender sessions for each outbound queue?
Thanks. |
|
| Back to top |
|
|
| mvic |
| Posted: Tue Feb 28, 2006 1:23 pm Post subject: |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| mqsnbmp1 wrote: |
| I have a follow up question -- how much overhead is in creating separate sessions for each receiver (except that it creates an additional thread, which is fine). Also, is there any harm in creating separate sender sessions for each outbound queue? |
Each JMS Session has its own MQI connection. In a client, this equates to a new TCP/IP network connection, to the same queue manager of course.
My best guess is that a new Session will potentially need an amount of memory, a new thread (I think only when an onMessage listener is registered - but am not sure), and a new connection to the queue manager - which if a client will require a new TCP/IP connection, and a slight increase in resources used by the queue manager. All of these resources are hopefully small in comparison with what the system as a whole requires - but to be certain, do some testing and confirm this in your own environment. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Feb 28, 2006 7:42 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
@mqsnbmp1
There is another aspect to this that should not escape your notice.
Transactionality is handled at the session level.
If your sessions are transacted it is important to have separate sessions for the separate queues.
If your queues are supposed to work in tandem it is not a good pattern to have listeners on each queue. You should just have a listener on the master queue and do a receive with correlationid selector (Note "ID:xxxxxx") for the second (child/slave) queue. This would also allow you to do the receive from the same session and as such keep the transactionality of the process intact.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqsnbmp1 |
| Posted: Wed Mar 01, 2006 5:51 am Post subject: |
|
|
Apprentice
Joined: 18 Oct 2005
Posts: 25
|
| fjb_saper wrote: |
@mqsnbmp1
There is another aspect to this that should not escape your notice.
Transactionality is handled at the session level.
If your sessions are transacted it is important to have separate sessions for the separate queues.
If your queues are supposed to work in tandem it is not a good pattern to have listeners on each queue. You should just have a listener on the master queue and do a receive with correlationid selector (Note "ID:xxxxxx") for the second (child/slave) queue. This would also allow you to do the receive from the same session and as such keep the transactionality of the process intact.
Enjoy |
Thanks. In my particular case the queues are independent, and the program simply does protocol conversion to/from TCP-IP Sockets byte streams from/to XML messages over JMS queues. In other words it is an interface adapter, and acts like a wire between two systems that use very different protocols and message formats. The specific situation I have has 2 channels one way and two channels the other way, and I was trying to combine it all in one asynchronously driven application. I ended up having separate sessions for each sender and receiver, and it seems to have very little resource overhead (separate thread for each receiver session, and separate socket connection for each sender). |
|
| 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
|
|
|
|
