activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Torsten Mielke (JIRA)" <>
Subject [jira] [Updated] (AMQ-3482) Make PooledConnectionFactory's sessionPool non-blocking in case its full.
Date Wed, 31 Aug 2011 16:21:09 GMT


Torsten Mielke updated AMQ-3482:

    Attachment: AMQ-3482.patch

Attaching a possible patch including JUnit test.
This patch allows to configure the behavior of the session pool once its full but changes
the default behavior to throw a javax.jms.JMSException: "Pool exhausted" in case the pool
is full (previous versions simply block).

The behavior is controlled by API PooledConnectionFactory.setBlockIfSessionPoolIsFull(boolean
block) and defaults to false (don't block but raise an exception).

> Make PooledConnectionFactory's sessionPool non-blocking in case its full.
> -------------------------------------------------------------------------
>                 Key: AMQ-3482
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Improvement
>         Environment: PooledConnectionFactory
>            Reporter: Torsten Mielke
>         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
> 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:


View raw message