activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Timothy Bish (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (AMQ-3482) Make PooledConnectionFactory's sessionPool non-blocking in case its full.
Date Thu, 01 Sep 2011 13:03:09 GMT

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

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

    Resolution: Fixed

Returned the default to blocking on session pool exhaustion.  

> 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

        

Mime
View raw message