You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Timothy Bish (JIRA)" <ji...@apache.org> on 2011/08/31 23:08:09 UTC

[jira] [Resolved] (AMQ-3482) Make PooledConnectionFactory's sessionPool non-blocking in case its full.

     [ https://issues.apache.org/jira/browse/AMQ-3482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Timothy Bish resolved AMQ-3482.
-------------------------------

       Resolution: Fixed
    Fix Version/s: 5.6.0

Patch applied, looks good, nice addition.  Thanks.

> Make PooledConnectionFactory's sessionPool non-blocking in case its full.
> -------------------------------------------------------------------------
>
>                 Key: AMQ-3482
>                 URL: https://issues.apache.org/jira/browse/AMQ-3482
>             Project: ActiveMQ
>          Issue Type: Improvement
>         Environment: PooledConnectionFactory
>            Reporter: Torsten Mielke
>             Fix For: 5.6.0
>
>         Attachments: AMQ-3482.patch
>
>
> When using the PooledConnectionFactory it internally caches the JMS Sessions. This is done using a commons pool. 
> The amount of sessions to be pooled is controlled by the maximumActive property of the PooledConnectionFactory. 
> Right now, when the session pool is full, then any further call to Connection.getSession() will block until a session is available from the pool.
> Depending on whether a connection is returned to the pool, this call might potentially block forever.
> IMHO this is not the best default behavior. Less experienced users might believe the JMS client is hung or suffering a bug if it simply does not return. There is currently no warning logged that this call will block, so no indication of the full session pool is given. 
> I propose to change this default behavior and raise a JMSException exception in case the session pool is full and no further Session can be created.
> The underlying commons-pool class org.apache.commons.pool.impl.GenericObjectPoolFactory can be configured easily to raise an ex rather than blocking. 
> This will indicate JMS clients that the session pool is full and allows them to take appropriate actions (retry later, or propagate the error upwards).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira