[
https://issues.apache.org/jira/browse/AMQ-4225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13533836#comment-13533836
]
Raul Kripalani commented on AMQ-4225:
-------------------------------------
[~wangyin], this has nothing to do with hypothetical pooling of
MessageConsumers. In response to:
bq. eventually you call the close method on the connection to return the
connection to the pool,if the consumer is closed by the pool then you won't get
any messages consumed any more.
>>> that's correct, and that's exactly what should happen. If the user code is
>>> closing a Connection, it expects to stop receiving messages, right?
As a matter of fact, activemq-pool seems to break the contract of the JMS
Connection class:
bq. There is no need to close the sessions, producers, and consumers of a
closed connection.
With the current implementation, if you close the Connection, you still need to
explicitly close any MessageConsumers that were created from it, or they'll
keep running forever.
Unfortunately, calling Connection.close() returns all sessions to the pool
(AMQ-2643), but it doesn't take care of closing MessageConsumers that were
created from it.
IMHO, this is a bug.
> PooledConnectionFactory should track Session checkouts and close associated
> resources
> -------------------------------------------------------------------------------------
>
> Key: AMQ-4225
> URL: https://issues.apache.org/jira/browse/AMQ-4225
> Project: ActiveMQ
> Issue Type: Improvement
> Affects Versions: 5.7.0
> Reporter: Raul Kripalani
>
> When the user's code closes a Connection checked out from the pool, I would
> expect activemq-pool to close Sessions, MessageConsumers and MessageProducers
> that were created from it.
> Unfortunately, activemq-pool only cleans up Sessions on Connection.close()
> when no one else is referencing the Connection (referenceCount == 0).
> This makes Sessions, Consumers and Producers outlive the code that actually
> uses them, thus leading to increased resource consumption and messages being
> trapped in prefetch buffers that are no longer monitored.
> Instead, we should keep track of the Sessions that were created from each
> specific Connection checkout, and close them when the borrowed Connection is
> closed.
> Otherwise we bump into situations like
> [SPR-10092|https://jira.springsource.org/browse/SPR-10092] when using
> Spring's DefaultMessageListenerContainer. In some cases DMLC "forgets" to
> explicitly close MessageConsumers and Sessions, even though Connections are
> always closed, but the pool doesn't take care of cleaning up associated
> sessions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
