Author |
Message
|
archit_agarwal |
Posted: Wed Feb 21, 2007 8:02 am Post subject: Weblogic + MQ(JMS) connection pooling |
|
|
Novice
Joined: 14 Jan 2006 Posts: 16
|
Hi All,
I am working on configuring IBM WebSphere MQ(JMS) on weblogic to integrate with.
I used Foreign JMS Server to configure the Jndi in Weblogic.
It is working fine. But it is too slow as compared to writing a simple program using MQ (by specifying q mgr, q, channel,port).
I tried to make the singleton class for Jndi lookup. But it fails after running the application runs on 300 threads.
It seems as if the sessions are not getting closed and there could be only 100 concurrent connections open on a single port.
Now I was thinking to implement some kind of connection/session pooling, so that I can make way to hold the request, if currently it is not available in the thread.
Does any body have an idea of connection pooling in MQ(JMS). I know MQ internally has some sort of connection pooling which we can play with using MQEnvironment, but here I am just trying to avoid any such very much specific MQ classes to be used.
Please help.
Thanks,
Archit |
|
Back to top |
|
 |
jefflowrey |
Posted: Wed Feb 21, 2007 8:17 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Your application server should provide any needed connection pooling.
Doing the lookup in a singleton is a horrible idea from a J2EE/JavaEnterprise perspective.
JMS is always going to be slow compared to the Java API for WebSphere MQ. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
archit_agarwal |
Posted: Wed Feb 21, 2007 9:59 am Post subject: |
|
|
Novice
Joined: 14 Jan 2006 Posts: 16
|
Weblogic Application server provides no way of pooling MQ (JMS) connections directly.
I require this while sending messages. Weblogic provides a mechanism for Session pools which could be useful while receiving messages not while sending messages.
Also, I didn't understand that why would you said that context looking in singleton is a horrible idea, though it makes the things faster, as seperate threads need not to look for the initial context everytime. And hence I can save InitialContext look-up everytime.
I tried to keep the context into the hashMap as well, but that would only utilize during the multiple look-ups in the same thread.
Even I am using JMS api using ConnectionFactory/Connection/session but by specifying the q mgr, q, channel,port instead of JNDI lookup for these everytime.
Any suggestion will be of great help.
Thanks,
Archit |
|
Back to top |
|
 |
jefflowrey |
Posted: Wed Feb 21, 2007 10:06 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
I don't think the InitialContext is going to be the same across all threads, particularly it may be different in a Servlet than an EJB.
I think it's likely a performance optimization that is unnecessary in almost all cases.
I believe that the JMS specification requires that an application server provide connection pooling capabilities.
Weblogic may have decided that only applied to it's messaging provider, rather than foreign providers.
You may find some useful information here:
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.csqzaw.doc/jms77afs.htm _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
archit_agarwal |
Posted: Wed Feb 21, 2007 1:53 pm Post subject: |
|
|
Novice
Joined: 14 Jan 2006 Posts: 16
|
Thanks Jeff!
but we are usig MQ version 5.3 and therefore I am not sure if I can use these properties.
Do you have an idea if these ASF classes/functions can still be used.
Yes it is more to do with performance optimization.
We used even servlet calls to find out if that also performs better. |
|
Back to top |
|
 |
jefflowrey |
Posted: Wed Feb 21, 2007 1:54 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
|
Back to top |
|
 |
|