[
https://issues.apache.org/activemq/browse/AMQ-1681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hiram Chirino resolved AMQ-1681.
--------------------------------
Fix Version/s: 5.1.0
Resolution: Fixed
This also occurred with temp topics.
Fixed in revision 651300
> Memory leak when creating large numbers of TemporaryQueues (Log4J related)
> --------------------------------------------------------------------------
>
> Key: AMQ-1681
> URL: https://issues.apache.org/activemq/browse/AMQ-1681
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.0.0
> Environment: Embedded broker using Log4J
> Reporter: Gregory Mostizky
> Assignee: Hiram Chirino
> Fix For: 5.1.0
>
>
> When using an embedded broker and using Log4J, there is a memory leak in the
> broker for each new TemporaryQueue created.
> This seems to be the offending code (taken from 5.0.0-release source):
> org.apache.activemq.broker.region.Queue:
> public Queue(Broker broker, ActiveMQDestination destination, final
> SystemUsage systemUsage, MessageStore store, DestinationStatistics
> parentStats,
> TaskRunnerFactory taskFactory, Store tmpStore) throws
> Exception {
> ... skipped....
> // let's copy the enabled property from the parent
> DestinationStatistics
> this.destinationStatistics.setEnabled(parentStats.isEnabled());
> destinationStatistics.setParent(parentStats);
> this.log = LogFactory.getLog(getClass().getName() + "." +
> destination.getPhysicalName());
> }
> What happens here is that for each new TemporaryQueue created a new log
> instance is created with rather large string as it's name.
> This instance is unique for each new TemoraryQueue and because of the way
> Log4J handles those instances, it is never removed once initalized.
> We hit this bug when we were testing performance together with Spring-based
> synchronous JMS API, which is implemented in such a way that
> for each new message it creates a new TemporaryQueue. We got OutOfMemory
> after about 40000 messages with 128M heap.
> I am not sure what this special log instance is used for, but assuming it's
> not very important, it will be easy to fix this bug with just using some
> predefined log name always.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
