| Author |
Message
|
| sboying |
 Posted: Fri Oct 13, 2006 10:47 am Post subject: Using JMS selector appears to be causing slow performance |
 |
|
Novice
Joined: 07 Sep 2006
Posts: 11
|
I have mulitple threads sending/receiving MQ msgs, at any given time an undetermined number of the the threads stall for a bit when either performing a send or receive. Using the msg selector has dramatically increased this behavior. I thought maybe it was due to not using Id:hexstring, but thats not the case. I use the msgId for correlation which is already a hexstring:
selector = "JMSCorrelationID='" + outMessage.getJMSMessageID() + "'";
System.out.println("selector as string= " + selector);
selector as string= JMSCorrelationID='ID:414d51204343545330342020202020204528bf84203b8127'
MQVER = 6.01
OS = solaris 5.8
Java = 1.4.2_03-b02
I understand msg selection should cause a bit of a slowdown, but I wasn't expecting this, any ideas? The unix boxes don't appear to be overloaded. |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Fri Oct 13, 2006 2:47 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Well apparently you are doing everything right.
The next question is how many messages are on the queue and how many processes have a selector on the queue?
At some point in time volume becomes a constraint...
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| sboying |
| Posted: Sun Oct 15, 2006 3:31 pm Post subject: |
|
|
Novice
Joined: 07 Sep 2006
Posts: 11
|
I believe after reading a bit more it appears each thread should use a separate connection. I currently have 1 connection servicing 4 threads which each put/get 1msg per sec and the other 16 threads using another "single" connection(most of the thread waits are here). If a connection can only perform 1 operation at a time, get or put and I have several threads wating to be serviced, seems I could be running into blocking issues. I am trying to be resource/performance conscience. So if I understand correctly I really need the ratio:
1-connection/1-session/1-thread
I'm still a little fuzzy why there is a socket created for each connection and also for each session? In this case I will use 40 sockets?
Thank you,
Shawn |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Oct 16, 2006 2:37 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Depends on what you call connection. To me it looks like each session has one. But looking at the documentation you might be right in having 1 connection = 1 session = 1 get operation on the same queue.
You might want to search the red books for the JMS Topology which has an excellent way for calculating what you need.
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| sboying |
| Posted: Mon Oct 16, 2006 5:31 am Post subject: |
|
|
Novice
Joined: 07 Sep 2006
Posts: 11
|
documentation states:
The implementation of WebSphere MQ classes for Java ensures that, for a given connection (MQQueueManager object instance), all access to the target WebSphere MQ queue manager is synchronized. A thread that wants to issue a call to a queue manager is blocked until all other calls in progress for that connection are complete. If you require simultaneous access to the same queue manager from multiple threads within your program, create a new MQQueueManager object for each thread that requires concurrent access. (This is equivalent to issuing a separate MQCONN call for each thread.)
From this its pretty clear, one connection per thread. One would probably want to create a pool of these for frequent users as well. I am desperately looking for documentation that shows the underlying TCP/IP sockets behavior when one creates a queueSession. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Oct 16, 2006 5:51 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The underlying TCP/IP sockets behavior is going to be the actual MQ Client protocol - which is undocumented and probably proprietary.
I think the documentation is reasonably clear that a single Connection can support more than one Session, and that the actual underlying connection is in the Connection and not in the Session.
So if you need fully multi-threaded behavior, you need more than one Connection, and of course therefore more than one session. You can use the ASF to implement a connection pool, if you aren't running in an app server environment (which should do this for you).
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| sboying |
| Posted: Mon Oct 16, 2006 6:25 am Post subject: |
|
|
Novice
Joined: 07 Sep 2006
Posts: 11
|
| Thanks all. I will create a connection per thread and post with the results. |
|
| Back to top |
|
|
| sboying |
| Posted: Wed Dec 13, 2006 11:38 am Post subject: |
|
|
Novice
Joined: 07 Sep 2006
Posts: 11
|
| I should have posted a reply some time ago. Our thread pause turned out be the Java Garbage Collector, we switched to the concurrent-low-pause collector and it helped greatly. Not a JMS/MQ problem. Thanks! |
|
| Back to top |
|
|
|
|
