| Author |
Message
|
| jay_green4 |
 Posted: Fri Jul 23, 2004 5:34 am Post subject: Connection Pools with MQ JMS |
 |
|
Newbie
Joined: 11 Nov 2003
Posts: 7
Location: UK
|
Hi,
I'm having a problem with our application running on WLS 7 that uses JMS to read and send messages to MQ. We have a numJMSber of beans deployed that send and receive messages to MQ queues via JMS.
This all works fine except there seems to be a problem in that when a bean is deployed a number of MQ connection channels are automatically created. This happens when the bean(s) are deployed and not when we use the queues to send or receive messages. We think this may be to do with connection pooling. This number of connections does seem to tie in with the initial and max beans set for the beans.
The main problem with this is that when a bean sends or receives a message a new connection channel is created and not one of the connections created when the bean was deployed. This is a bit confusing as we have these connections that just seem to be created and then not used. This uses up memory on the MQ server.
Has anyone experienced similar behavious like this? I don't really want to have start managing the connection pooling & would rather connectios are just created as needed. Is there a way to turn pooling for the Conn Factory off? (I tried setUseConnectionPooling(false) but it doesn't help.
Many thanks,
Jay. |
|
| Back to top |
|
 |
| RogerLacroix |
| Posted: Fri Jul 23, 2004 8:49 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
It is in your 'Deployment Descriptor':
| Code: |
<weblogic-ejb-jar>
<weblogic-enterprise-bean>
<ejb-name>XXXXEventListenerBean</ejb-name>
<message-driven-descriptor>
<pool>
<max-beans-in-free-pool>25</max-beans-in-free-pool>
<initial-beans-in-free-pool>5</initial-beans-in-free-pool>
</pool>
|
Just update the min & max values to whatever you want.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| jay_green4 |
| Posted: Mon Jul 26, 2004 12:41 am Post subject: |
|
|
Newbie
Joined: 11 Nov 2003
Posts: 7
Location: UK
|
Yeah, I understand how to configure a bean's descriptor. The problem we seem to be having is that connections are being created to MQ but then not used.
I also find it a little odd that if we set initial beans to 0 and max beans to a number then a number of conenctions are created to MQ as per the max number when the bean deploys. I would expect 0 connections & connections to be created as and when needed.
Is this typical of how MQ JMS works?
Cheers, Jay. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Mon Jul 26, 2004 7:59 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
The purpose of the connection pool is to allow you / your application an automatic throttling control over the connections. Hence, the min value will be the number of connections automatically openned.
I have no idea what will happen if you use min value equal to zero. Strongly, suggest that you use min of 1 and maybe max of 3.
Your application seems rather strange. You are building and deploying an application within WebLogic that will ONLY have 1 user (or maybe 1 serial request at a time)!!!! What is the point of using WebLogic? A whole lot of overhead for little or no benefit.
Normally for application servers, you want to handle several concurrent requests (i.e. 5, 10, 100, etc...) at the same time. Therefore, having connection pools for MQ or database is very beneficial for your application. The J2EE component will throttle up and down the number of connections to an external resource as the application does its work.
As a rule of thumb, I use 5-to-1 ratio when defining pools. If I expect a peek of 100 concurrent incoming requests then I will set the pool's max value to 20. And if normal load is 30 concurrent incoming requests then I set the min value to 6.
These are ONLY guidelines and you should do real (simulate) load testing to see how your application performs with these pool values.
Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| jay_green4 |
| Posted: Tue Jul 27, 2004 5:33 am Post subject: |
|
|
Newbie
Joined: 11 Nov 2003
Posts: 7
Location: UK
|
Roger,
Many thanks for taking the reply to my queries.
We know how to set our bean pool values. I think my post was confusing as I just provided example values that I tested to see what was going on and to invesigate this behaviour.
The overall problem is that our EJB's/MDB's deployed on WLS that send and receive to MQ's are creating channel connections on MQ at deployment time. The amount of connections seems to be related to the bean pool values set in the descriptors.
I can understand how a connection pool would reserve these connections but the problem we are finding is the connections are created when beans are deployed and never get used. They seem to just get reserved and use up MQ resources. If we instantiate a bean another connection is created and not one of the connections created at deployment.
The query is really is this how this is expected to work? If not could it be something I'm setting up wrong (probably in MQ?).
Because we have multiple beans that connect to MQ we can find that a very large number of connections are created that use up memory and don't seem to get re-used.
I hope this makes sense?
Cheers, Jay. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Jul 27, 2004 9:18 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
When you setup your EJB 2 things
1) WAS inbound : MDB put a MessageListener on the queue.
As many connections to the queue as instances of the bean.
2) WAS Outbound messages :
When the bean gets instanciated you acquire the resource (o.K.)
What do you do when the bean gets passivated ?
What do you do when the bean gets disposed ?
Remember to think about releasing the resource when no longer needed. And remember to have the container handle this part of the process!
Enjoy |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jul 27, 2004 11:33 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Jay, I feel your pain. As more and more apps are using JMS, are QMs are taking a pounding, even if the app is coded 100% correctly. JMS just does so many connects and opens and inquiries even when there are no messages flowing.
Add to the mix a scenario where something is not 100%, and you start seeing your Listeners max out with 100s and 100s of unused JMS connections...
JMS proper is a mystery to me. But one of our JMS gurus sent the below to me as we were trying to figure out the problem. I can't expound on it further, but maybe it will help?
| Quote: |
If it helps, my research has found that large number of connection type problems with MQ and Weblogic are fairly common. The problem stems from how IBM MQ implements some JMS functionality is different than what Bea considers "normal".
In JMS there are two basic Objects - a Connection Object, and a Session object. The Session object is obtained from a Connection object.
Under IBM's implementation, every single session object gets a physical connection back to MQ. According to bea this is because IBM's connections are not thread safe so their implementation requires individual connections per session. In other words if a Java application has 1 connection and 20 associated sessions, with IBM drivers you get 20 physical connections (and file descriptors used) while with some other vendors JMS implementations you would have 1 physical connection.
Because bea programmers were not thinking session=physical connection, in cases of restart they were not closing sessions - I think they were simply creating new ones. This led to cases in weblogic where sessions and the associated physical connections became orphaned. Only a complete shutdown of weblogic frees these resources. This problem has happened on multiple versions of weblogic, and the latest service pack adresses these issues (they call close on the sessions).
I am also interested if IBM has been issuing any newer JMS drivers. Our JMS drivers come from the standard MQ install on the boxes.
|
What do you think?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jul 27, 2004 11:34 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Quote: |
We determined that Weblogic 6.1 SP 5 does have a problem accumulating connections around MQ outages. We roughly see a doubling per outage, and our application servers have been up 100 days+ between recycles. In the short term we have taken to recycling our servers when possible, which has alleviated the production problem. The long term solution is two fold: application of the Weblogic service pack to prevent orphaned connections, and minimizing the number of MDBs that we deploy.
We have migrated the Weblogic 6.1 service pack 6 through our Dev and QA environments and Production is scheduled for June 4th.
The other solution is minimizing the number of MDBs (Message Driven Beans) that we deploy. In the original design for Broker Alerts we decided to use multiple MDBs and multiple queues in order to allow potential monitoring of the application at a more fine grained level. I.E. if we later decided to deploy tools that could report on activity, we could sit on top of MQ and get a detailed view of what is happening at that moment.
Ultimately, the number of MDBs deployed has very direct relationship to the number of connections. For every MDB a pool of connections is maintained by weblogic which can be roughly 1-30 connections or so per MDB. Our experience with MQ to date is that it is very likely to see the server holding 50+ connections to MQ. This situation is further worsened by the fact that we have multiple machines for clustering to support high availability. So if we have 2 servers we end up with 100 connections to MQ. Since our boxes will eventually support failover between the Simsbury/Hartford MQ that would double the connections on our side (100 per datacenter).
Since Weblogic pools connections individually between MDBs, it is an inefficient use of connections (and the associated resources) for our applications to use large numbers. An example of this is the case where I have 2 MDBs each with a pool of 5 connections for 10 connections total. If MDB 1 has 10 simultaneous units of work, it will create 5 more connections since it does not share connections between the independent pools. If MDB2 were idle at that point we would have the situation where we had 5 idle connections to MQ (MDB 2) yet still went out and made 5 more (MDB 1).
|
I also found this from him...
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| jay_green4 |
| Posted: Thu Jul 29, 2004 3:07 am Post subject: |
|
|
Newbie
Joined: 11 Nov 2003
Posts: 7
Location: UK
|
Many thanks Peter. This is the kind of information I was after.
We're running WLS 7 SP2. Has anyone else experienced this problem and know if there is a BEA SP that fixes this? |
|
| Back to top |
|
|
|
|
