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:17:09 UTC
[jira] [Created] (AMQ-3482) Make PooledConnectionFactory's
sessionPool non-blocking in case its full.
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
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
[jira] [Reopened] (AMQ-3482) Make PooledConnectionFactory's
sessionPool non-blocking in case its full.
Posted by "Timothy Bish (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Timothy Bish reopened AMQ-3482:
-------------------------------
Return the default behavior to blocking.
> 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
[jira] [Commented] (AMQ-3482) Make PooledConnectionFactory's
sessionPool non-blocking in case its full.
Posted by "Gary Tully (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13095214#comment-13095214 ]
Gary Tully commented on AMQ-3482:
---------------------------------
I would not be in favor of changing the default blocking behavior, I think the exiting default is sensible. +1 for making it configurable though.
> 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
[jira] [Commented] (AMQ-3482) Make PooledConnectionFactory's
sessionPool non-blocking in case its full.
Posted by "Claus Ibsen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13095122#comment-13095122 ]
Claus Ibsen commented on AMQ-3482:
----------------------------------
This change should be clearly documented IMHO in the release notes / important change to consider when upgrading etc. And examples given how to configure this like the old way etc.
> 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
[jira] [Updated] (AMQ-3482) Make PooledConnectionFactory's
sessionPool non-blocking in case its full.
Posted by "Torsten Mielke (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Resolved] (AMQ-3482) Make PooledConnectionFactory's
sessionPool non-blocking in case its full.
Posted by "Timothy Bish (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Resolved] (AMQ-3482) Make PooledConnectionFactory's
sessionPool non-blocking in case its full.
Posted by "Timothy Bish (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Timothy Bish resolved AMQ-3482.
-------------------------------
Resolution: Fixed
Fix Version/s: 5.6.0
Patch applied, looks good, nice addition. Thanks.
> 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