You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Michael Pilone (JIRA)" <ji...@apache.org> on 2012/07/18 18:23:34 UTC
[jira] [Created] (AMQ-3938) Memory Leak w/Temporary Queues and JMX
Michael Pilone created AMQ-3938:
-----------------------------------
Summary: 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
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
[jira] [Comment Edited] (AMQ-3938) Memory Leak w/Temporary Queues
and JMX
Posted by "Michael Pilone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13417627#comment-13417627 ]
Michael Pilone edited comment on AMQ-3938 at 7/18/12 8:01 PM:
--------------------------------------------------------------
Looking at the JMX info via JConsole, I can see that under org.apache.activemq->Broker Name->Producer->TempQueue there are hundreds or thousands of entries. Way more than what is under ...->Broker Name->TempQueue which contains about 45 entries. This is after running the broker for 8 days, about half of the expected life before exhausting memory.
What puts entries under Producer and does it ever clean them up?
was (Author: mpilone):
Looking at the JMX info via JConsole, I can see that under org.apache.activemq->Broker Name->Producer->TempQueue there are hundreds or thousands of entries. Way more than what is under ...->Broker Name->TempQueue which contains about 45 entries.
What puts entries under Producer and does it ever clean them up?
> 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
[jira] [Commented] (AMQ-3938) Memory Leak w/Temporary Queues and
JMX
Posted by "Michael Pilone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13417627#comment-13417627 ]
Michael Pilone commented on AMQ-3938:
-------------------------------------
Looking at the JMX info via JConsole, I can see that under org.apache.activemq->Broker Name->Producer->TempQueue there are hundreds or thousands of entries. Way more than what is under ...->Broker Name->TempQueue which contains about 45 entries.
What puts entries under Producer and does it ever clean them up?
> 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
[jira] [Commented] (AMQ-3938) Memory Leak w/Temporary Queues and
JMX
Posted by "Timothy Bish (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13426814#comment-13426814 ]
Timothy Bish commented on AMQ-3938:
-----------------------------------
Have you enabled the cleanup of inactive destinations? See:
http://activemq.apache.org/delete-inactive-destinations.html
> 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
[jira] [Commented] (AMQ-3938) Memory Leak w/Temporary Queues and
JMX
Posted by "Michael Pilone (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Comment Edited] (AMQ-3938) Memory Leak w/Temporary Queues
and JMX
Posted by "Michael Pilone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13417627#comment-13417627 ]
Michael Pilone edited comment on AMQ-3938 at 7/18/12 8:02 PM:
--------------------------------------------------------------
Looking at the JMX info via JConsole, I can see that under org.apache.activemq->Broker Name->Producer->TempQueue there are hundreds or thousands of entries. Way more than what is under org.apache.activemq->Broker Name->TempQueue which contains about 45 entries. This is after running the broker for 8 days, about half of the expected life before exhausting memory.
What puts entries under Producer and does it ever clean them up?
was (Author: mpilone):
Looking at the JMX info via JConsole, I can see that under org.apache.activemq->Broker Name->Producer->TempQueue there are hundreds or thousands of entries. Way more than what is under ...->Broker Name->TempQueue which contains about 45 entries. This is after running the broker for 8 days, about half of the expected life before exhausting memory.
What puts entries under Producer and does it ever clean them up?
> 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
[jira] [Updated] (AMQ-3938) Memory Leak w/Temporary Queues and JMX
Posted by "Michael Pilone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael Pilone updated AMQ-3938:
--------------------------------
Attachment: Eclipse Memory Analyzer_2012-07-18_11-46-58.png
Attached screenshot of MAT leak suspects.
> 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
[jira] [Commented] (AMQ-3938) Memory Leak w/Temporary Queues and
JMX
Posted by "Michael Pilone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13417224#comment-13417224 ]
Michael Pilone commented on AMQ-3938:
-------------------------------------
The memory dump is too large to attach so I've compressed it and posted it here:
https://dl.dropbox.com/u/3337852/grand-central.wl2-prod.2012-07-09_16-41-37.hprof.zip
> 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
[jira] [Closed] (AMQ-3938) Memory Leak w/Temporary Queues and JMX
Posted by "Timothy Bish (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Timothy Bish closed AMQ-3938.
-----------------------------
Resolution: Not A Problem
User indicates this is a non-issue.
> 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
[jira] [Commented] (AMQ-3938) Memory Leak w/Temporary Queues and
JMX
Posted by "Michael Pilone (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (AMQ-3938) Memory Leak w/Temporary Queues and
JMX
Posted by "Robert Schettini (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13427690#comment-13427690 ]
Robert Schettini commented on AMQ-3938:
---------------------------------------
Thanks for the suggestion. I tried it but it did not help. The new clue I discovered today is that the PermGen space can be reclaimed if ALL connections to ActiveMQ are closed.
> 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
[jira] [Commented] (AMQ-3938) Memory Leak w/Temporary Queues and
JMX
Posted by "Robert Schettini (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/AMQ-3938?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13424006#comment-13424006 ]
Robert Schettini commented on AMQ-3938:
---------------------------------------
We are experiencing a very similar issue. We create a lot of temporary queues and JMX is turned on, we consume all of PermGen very quickly. When JMX is off, we can "run forever". Running the code below, I can observer the permgen space using jvisualvm:
ActiveMQConnectionFactory cf = new ActiveMQConnctionFactory(new URI("<my borker>"));
Connection c = cf.createConnection();
Session s = c.createSession(false, Session.AUTO_ACKNOWLEDGE);
for (int i=0; i<10000; i++)
{
TemporaryQueue q = s.createTemporaryQueue();
q.delete();
}
s.close();
c.close();
> 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