[
http://jira.jboss.com/jira/browse/JBMESSAGING-864?page=comments#action_12... ]
Tim Fox commented on JBMESSAGING-864:
-------------------------------------
After some thought, actually I don't think this would be too hard to fix in the 1.0.sp
branch.
When a consumer is closed currently we don't actually get rid of it since it might
have unacked deliveries.
But when doing the close we can check whether it has unacked deliveries and if so remove
it there and then. In this way it should work with the JCA ant-pattern if people want to
do that.
Memory leak when using JCA layer and creating consumer on each send
-------------------------------------------------------------------
Key: JBMESSAGING-864
URL:
http://jira.jboss.com/jira/browse/JBMESSAGING-864
Project: JBoss Messaging
Issue Type: Bug
Affects Versions: 1.0.1.SP4
Reporter: Tim Fox
Assigned To: Tim Fox
If using the JCA adapter and performing the following anti-pattern:
create connection
create session
create consumer
message = consumer.receive(..)
in order to recieve a single message (this is what the spring jms template apparently
does - yikes)
Then the JCA layer will cache the connection and session, but the consumer will get
created anew on the server each time. This in itself means the operation will be very slow
- hence I consider this an antipattern.
Since the JCA layer re-uses the session, it never gets closed. In the 1_0 branch
deliveries are maintained in the consumer, not the session, so consumer.close() does not
actually close the consumers - this happens on session.close(). Hence the leak.
This does not affect the 1.2 branch where deliveries are stored on the session level.
My recommendation to people would be not to use this antipattern in the first place. This
may mean not using the Spring jms template which unfortunatelt seems to be poorly coded to
work this way.
Also see
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4019590#...
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=102169
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira