[
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
