You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Torsten Mielke (JIRA)" <ji...@apache.org> on 2011/08/31 18:21:09 UTC
[jira] [Updated] (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 ]
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: https://issues.apache.org/jira/browse/AMQ-3482
> 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 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