[
https://issues.apache.org/jira/browse/AMQ-3938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13418315#comment-13418315
]
Michael Pilone commented on AMQ-3938:
-------------------------------------
After some more testing I was able to determine that indeed this was user
error. The Spring CachingConnectionFactory defaults to caching an unlimited
number of producers. This causes problems when a new producer is request to
send a reply message on a temporary queue because a new producer is created and
cached for each reply message (assuming the same temporary queue isn't reused).
So the lesson is, disable producer caching when using:
- Spring's CachingConnectionFactory
- Apache Camel
- Request/Reply messages on temporary queues
You can reject/close this defect. Sorry for the trouble.
> Memory Leak w/Temporary Queues and JMX
> --------------------------------------
>
> Key: AMQ-3938
> URL: https://issues.apache.org/jira/browse/AMQ-3938
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker, JMX
> Affects Versions: 5.6.0
> Environment: Java 6
> ActiveMQ 5.6.0
> Apache Camel 2.10.0
> Network of brokers (2 nodes)
> Solaris
> Reporter: Michael Pilone
> Attachments: Eclipse Memory Analyzer_2012-07-18_11-46-58.png
>
>
> I'm seeing a slow memory leak in our broker process which appears to be
> related to temporary queues and JMX. We had major memory leak problems
> before, but the 5.6.0 release fixed the majority of them. This leak seems to
> take about 2 weeks to fill 512MB heap but ultimately it will bring down the
> JVM.
>
> The process which eventually runs out of memory simply runs an embeded broker
> which other clients connected to it via TCP. There are a couple static Camel
> routes, but nothing major in this process. Other clients (connected via TCP)
> make heavy use of pooled connections, Apache Camel, and temporary queues for
> request/reply messaging.
>
> I'm still looking into the issue but I've attached a MAT memory analysis to
> see if anyone else has seen a related problem. It looks like the temporary
> queues are getting registered in JMX and never removed but I'm just guessing
> right now.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
