activemq-dev mailing list archives

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

     [ 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

        

Mime
View raw message