Memory leak when creating large numbers of TemporaryQueues (Log4J related)

• Key: AMQ-1681
• Type: Bug
• Status: Resolved
• Resolution: Fixed
• Priority: Major
• Assignee: Hiram Chirino
• Reporter: Gregory Mostizky
• Component/s: Broker
• Affects Version/s: 5.0.0
• Fix Version/s: 5.1.0

Description

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.

Comments

This also occurred with temp topics.

Fixed in revision 651300