2 Replies Latest reply on Mar 13, 2007 5:16 AM by Thomas Rois

    Help understanding ManagedConnectionPool Behaviour

    David M Newbie

      We're using JBoss 4, and we're having some trouble with excessive database connections being made by JBoss's ManagedConnectionPool. From OpenNMS, our monitoring software, we can usually see the number of connections held in the connection pool by each node in our cluster, and the number in active use. We're seeing a lot of connections being grabbed by JBoss nodes in sudden spikes, but few to none being actively used, and it's a little puzzling.

      Does anyone know, when does JBoss open new database connections in it's pool? What algorithm does it use? Is it always in direct response to real usage? Does anyone have links to pages that describe JBoss's approach?

      Thanks for any help!
      David M.

        • 1. Re: Help understanding ManagedConnectionPool Behaviour
          David M Newbie

          Responding to myself, I've been looking through the JBoss code, and it seems like the connections are managed in internal subpools. Whenever a connection is requested, JBoss tries to allocate from an existing subpool. If there are no free connections in the existings subpools, a new subpool is created, and a connection is taken from there.

          If this is true, it would seem that JBoss does not have any background thread that watches the usage count and allocating when the free connections are getting low, or when it hits a certain threshold, or any similiar mechanism. It allocates new connections exactly when there are zero available connections.

          Can anyone confirm that I am understanding JBoss's ManagedConnectionPool behaviour correctly?

          Thanks for any help,
          David M.

          • 2. Re: Help understanding ManagedConnectionPool Behaviour
            Thomas Rois Newbie

            there are four optional parameters to configure your connection pool.

            min-pool-size (default: 0 = none)
            max-pool-sie (default:20)
            idle-timeout-minutes(default:0 = infinite)

            if you have high peek concurrency, you can try setting the timeout to a reasonable timing.
            max-size is hardcapped - you cannot get over this value at any rate.

            actually, the pool behaviour ( - which pool is chosen) depends on your xml-datasource configuration: