You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Eugene Rodos (JIRA)" <ji...@apache.org> on 2010/07/20 00:10:52 UTC
[jira] Created: (AMQ-2838) Memory Leak when using
ConnectionConsumer and a Persistent Broker
Memory Leak when using ConnectionConsumer and a Persistent Broker
-----------------------------------------------------------------
Key: AMQ-2838
URL: https://issues.apache.org/activemq/browse/AMQ-2838
Project: ActiveMQ
Issue Type: Bug
Components: Broker
Affects Versions: 5.3.1
Reporter: Eugene Rodos
I found a memory leak in ActiveMQ when using an embedded broker with persistence (enabled by default) and using the connection to create a ConnectionConsumer. The memory leak occurs after performing the following steps:
1. acquire a Connection (ActiveMQConnection) from a ConnectionFactory (ActiveMQConnectionFactory)
2. use the Connection to create a ConnectionConsumer
3. close the ConnectionConsumer
4. close the Connection
5. repeat steps 1 and 4 from above
The memory leak is in org.apache.activemq.thread.Scheduler. After the last connection is closed, the embedded broker is shutdown. When this happens all AMQ threads are killed except for the "ActiveMQ Scheduler" thread. This is a Timer that contains a queue of scheduled tasks. If no brokers are running, this queue should be empty. In fact if persistence is turned off on the broker, the queue is correctly emptied after the last connection is closed. However, with persistence on, the queue does not get emptied completely.
The memory leak is directly proportional to the number of ConnectionConsumers that are created on the connection. That is, the more ConnectionConsumers are created, the more tasks will remain on the Scheduler's task queue after the connection is closed.
In our test environment, we create many ConnectionConsumer objects for each test and run many such tests. The memory leak accumulates quickly and we soon get an OutOfMemoryException.
I'm attaching a junit test that illustrates the problem. The NUM_OF_CYCLES and NUM_OF_CONNECTION_CONSUMERS constants can be increased to see how the memory leak grows with increased number of iterations and ConnectionConsumer objects created, respectively. Also, persistence can be turned off on the broker url to see that the test succeeds in that case (i.e. no RAM leak).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (AMQ-2838) Memory Leak when using
ConnectionConsumer and a Persistent Broker
Posted by "Eugene Rodos (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Eugene Rodos updated AMQ-2838:
------------------------------
Attachment: ConnectionConsumerMemoryLeakTest.java
> Memory Leak when using ConnectionConsumer and a Persistent Broker
> -----------------------------------------------------------------
>
> Key: AMQ-2838
> URL: https://issues.apache.org/activemq/browse/AMQ-2838
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.3.1
> Reporter: Eugene Rodos
> Attachments: ConnectionConsumerMemoryLeakTest.java
>
>
> I found a memory leak in ActiveMQ when using an embedded broker with persistence (enabled by default) and using the connection to create a ConnectionConsumer. The memory leak occurs after performing the following steps:
> 1. acquire a Connection (ActiveMQConnection) from a ConnectionFactory (ActiveMQConnectionFactory)
> 2. use the Connection to create a ConnectionConsumer
> 3. close the ConnectionConsumer
> 4. close the Connection
> 5. repeat steps 1 and 4 from above
> The memory leak is in org.apache.activemq.thread.Scheduler. After the last connection is closed, the embedded broker is shutdown. When this happens all AMQ threads are killed except for the "ActiveMQ Scheduler" thread. This is a Timer that contains a queue of scheduled tasks. If no brokers are running, this queue should be empty. In fact if persistence is turned off on the broker, the queue is correctly emptied after the last connection is closed. However, with persistence on, the queue does not get emptied completely.
> The memory leak is directly proportional to the number of ConnectionConsumers that are created on the connection. That is, the more ConnectionConsumers are created, the more tasks will remain on the Scheduler's task queue after the connection is closed.
> In our test environment, we create many ConnectionConsumer objects for each test and run many such tests. The memory leak accumulates quickly and we soon get an OutOfMemoryException.
> I'm attaching a junit test that illustrates the problem. The NUM_OF_CYCLES and NUM_OF_CONNECTION_CONSUMERS constants can be increased to see how the memory leak grows with increased number of iterations and ConnectionConsumer objects created, respectively. Also, persistence can be turned off on the broker url to see that the test succeeds in that case (i.e. no RAM leak).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (AMQ-2838) Memory Leak when using
ConnectionConsumer and a Persistent Broker
Posted by "Rob Davies (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rob Davies reassigned AMQ-2838:
-------------------------------
Assignee: Rob Davies
> Memory Leak when using ConnectionConsumer and a Persistent Broker
> -----------------------------------------------------------------
>
> Key: AMQ-2838
> URL: https://issues.apache.org/activemq/browse/AMQ-2838
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.3.1
> Reporter: Eugene Rodos
> Assignee: Rob Davies
> Attachments: ConnectionConsumerMemoryLeakTest.java
>
>
> I found a memory leak in ActiveMQ when using an embedded broker with persistence (enabled by default) and using the connection to create a ConnectionConsumer. The memory leak occurs after performing the following steps:
> 1. acquire a Connection (ActiveMQConnection) from a ConnectionFactory (ActiveMQConnectionFactory)
> 2. use the Connection to create a ConnectionConsumer
> 3. close the ConnectionConsumer
> 4. close the Connection
> 5. repeat steps 1 and 4 from above
> The memory leak is in org.apache.activemq.thread.Scheduler. After the last connection is closed, the embedded broker is shutdown. When this happens all AMQ threads are killed except for the "ActiveMQ Scheduler" thread. This is a Timer that contains a queue of scheduled tasks. If no brokers are running, this queue should be empty. In fact if persistence is turned off on the broker, the queue is correctly emptied after the last connection is closed. However, with persistence on, the queue does not get emptied completely.
> The memory leak is directly proportional to the number of ConnectionConsumers that are created on the connection. That is, the more ConnectionConsumers are created, the more tasks will remain on the Scheduler's task queue after the connection is closed.
> In our test environment, we create many ConnectionConsumer objects for each test and run many such tests. The memory leak accumulates quickly and we soon get an OutOfMemoryException.
> I'm attaching a junit test that illustrates the problem. The NUM_OF_CYCLES and NUM_OF_CONNECTION_CONSUMERS constants can be increased to see how the memory leak grows with increased number of iterations and ConnectionConsumer objects created, respectively. Also, persistence can be turned off on the broker url to see that the test succeeds in that case (i.e. no RAM leak).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (AMQ-2838) Memory Leak when using
ConnectionConsumer and a Persistent Broker
Posted by "Rob Davies (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/activemq/browse/AMQ-2838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rob Davies resolved AMQ-2838.
-----------------------------
Fix Version/s: 5.4.0
Resolution: Fixed
The use of static classes (like Scheduler) is no longer used in ActiveMQ to prevent problems like this
> Memory Leak when using ConnectionConsumer and a Persistent Broker
> -----------------------------------------------------------------
>
> Key: AMQ-2838
> URL: https://issues.apache.org/activemq/browse/AMQ-2838
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.3.1
> Reporter: Eugene Rodos
> Assignee: Rob Davies
> Fix For: 5.4.0
>
> Attachments: ConnectionConsumerMemoryLeakTest.java
>
>
> I found a memory leak in ActiveMQ when using an embedded broker with persistence (enabled by default) and using the connection to create a ConnectionConsumer. The memory leak occurs after performing the following steps:
> 1. acquire a Connection (ActiveMQConnection) from a ConnectionFactory (ActiveMQConnectionFactory)
> 2. use the Connection to create a ConnectionConsumer
> 3. close the ConnectionConsumer
> 4. close the Connection
> 5. repeat steps 1 and 4 from above
> The memory leak is in org.apache.activemq.thread.Scheduler. After the last connection is closed, the embedded broker is shutdown. When this happens all AMQ threads are killed except for the "ActiveMQ Scheduler" thread. This is a Timer that contains a queue of scheduled tasks. If no brokers are running, this queue should be empty. In fact if persistence is turned off on the broker, the queue is correctly emptied after the last connection is closed. However, with persistence on, the queue does not get emptied completely.
> The memory leak is directly proportional to the number of ConnectionConsumers that are created on the connection. That is, the more ConnectionConsumers are created, the more tasks will remain on the Scheduler's task queue after the connection is closed.
> In our test environment, we create many ConnectionConsumer objects for each test and run many such tests. The memory leak accumulates quickly and we soon get an OutOfMemoryException.
> I'm attaching a junit test that illustrates the problem. The NUM_OF_CYCLES and NUM_OF_CONNECTION_CONSUMERS constants can be increased to see how the memory leak grows with increased number of iterations and ConnectionConsumer objects created, respectively. Also, persistence can be turned off on the broker url to see that the test succeeds in that case (i.e. no RAM leak).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.