[
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.
