activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Pilone (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (AMQ-3938) Memory Leak w/Temporary Queues and JMX
Date Wed, 18 Jul 2012 21:01:34 GMT

    [ https://issues.apache.org/jira/browse/AMQ-3938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13417675#comment-13417675
] 

Michael Pilone commented on AMQ-3938:
-------------------------------------

After some more digging I'm wondering if this is related to the clients to the broker using
Apache Camel for request/reply messages. We're using Spring's CachingConnectionFactory in
the clients and it looks like Camel use Spring's JmsTemplate to send a reply on a request
reply. It may be possible that JmsTemplate is creating a new MessageProducer for the reply
which is getting cached in the CachingConnectionFactory. Because the reply queues are temporary
and may change over time, the cached producers are never getting reused or released. I'll
have to look at the Spring source to see if they have any maximum to the number of cached
producers and see if I can setup some kind of test case. It still seems odd that this could
generate thousands of producers/JMX entries, but not out of the question.
                
> 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

        

Mime
View raw message