1 Reply Latest reply on May 23, 2011 3:16 PM by mp911de

    JMS Managed Connection pool sizing

    jharlow1
    jharlow1 Feb 15, 2011 5:47 PM

      Hi,

       

      I'm a fairly new JBoss administrator of an application that uses JMS messaging pretty heavily. One of the places where it is used is on a client workspace that receives real-time calculation updates. We are currently running on JBoss 4.2.3GA on Solaris 10 sparc.

       

      We started running into problems when the system is under load where we start getting errors like:

       

      javax.jms.JMSException: Could not create a session: javax.resource.ResourceException: No ManagedConnections available within configured blocking timeout ( 30000 [ms] )

       

      Using the JMX console, i have determined that when a user launches a particular workspace, depending on what options they use, it can tack on anywhere from 5 to 15 JMS connections to the pool and keep ahold of them until the user exits their session. Once the # hits the max pool size performance starts going down as the multiple users start vying for each others connections from the pool.

       

      I've determined based on this that to get rid of the error, I can increase the size of the pool in deploy/jms/jms-ds.xml. I increased from the default 20 to 100, and this seems to work. The application is stable again and I am not getting the errors.

       

      I have a couple of questions though based on this scenario in regards to scalability.

       

      1) Is that # of connections per user session reasonable, or should I be pushing back at the development team to dial that down?

      2) What are the practical limitations of increasing the JMS pool beyond 100 connections, and what are the implications of doing so?

      3) Are there any other places where I would likely have to tune related to this that I might be missing thus far?

      • 5403 Views
      • Tags:
        • 1. JMS Managed Connection pool sizing
          mp911de
          mp911de May 23, 2011 3:16 PM (in response to jharlow1)

          Hi Jason,

          each connection costs memory and cpu, so fewer is much better.

           

          But you can't limit in every scenario the connections to 10 connections or so. Each app has it's very own requirements. Basically, if the app sends on each web request a JMS Message, a connection per user/webrequest? would be ok to have one connection per user, but you should not bind a JMS connection to a user's session. When a Web-Requests starts, you create one connection, do your work and close the connection. To determine, how much connections you need, you could monitor JMS activity for a certain time.

           

          It's very important, to free each connection when it's not needed anymore. Too much open connections can cause locks due transactional locks.

          Best regards,

          Mark

            • Actions