activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gregory Mostizky (JIRA)" <j...@apache.org>
Subject [jira] Created: (AMQ-1681) Memory leak when creating large numbers of TemporaryQueues (Log4J related)
Date Wed, 23 Apr 2008 11:20:43 GMT
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


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.


Mime
View raw message