Mailing-List: contact dev-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@activemq.apache.org
Message-ID: <246604373.1208949643448.JavaMail.jira@brutus>
Date: Wed, 23 Apr 2008 04:20:43 -0700 (PDT)
From: "Gregory Mostizky (JIRA)" <jira@apache.org>
To: dev@activemq.apache.org
Subject: [jira] Created: (AMQ-1681) Memory leak when creating large numbers
 of TemporaryQueues (Log4J related)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

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.