activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: ActiveMQ 4.x memory leak in multithreaded applications
Date Mon, 21 Aug 2006 08:41:21 GMT
Note that using JmsTemplate without some pooling is a very inefficient
way of working with JMS. JmsTemplate is generally not recommended for
consuming messages. The PooledConnectionFactory only pools for sending
messages - not consuming them. To consume messages with pooled I'd
recommend you either use Spring 2's consumer containers or Jencks.

On 8/19/06, Alex Makarenko <> wrote:
> Hello everyone!
> I discovered some strange behavior of ActiveMQ 4.x in terms of
> MessageConsumer handling. It seamed that ActiveMQ 4.x versions in some cases
> do not release MessageConsumers while versions 3.2.x do.
> I have application that must work with limited system resources such as
> number of threads and number of simultaneously running tasks on message
> processing. A cannot use asynchronous message processing instead I have to
> use thread pool with 3 threads. Every thread creates MessageConsumer and
> tries to process message in case of failures massage is rolled back to
> queue. MessageConsumers are created to support independant transactions for
> every thread.
> Initially I was using ActiveMQ 4.0.1   Spring's JmsTemplate and
> TransactionTemplate. But after day or two of work I've got OutOfMemoryError.
> I tried to dig what's going on with YourKit Java Profiler and discovered
> that ActiveMQMessageConsumer objects that was created with JmsTemplate in
> each thread are still in memory and never get garbage collected. I thought
> it's a Spring bug but when I rewrote application to use clean JMS the
> situation do not changed.
> I am attaching screen shots from YourKit Java Profiler with Spring and
> without; along with sample application. It seams that ActiveMQ leaks
> MessageConsumers. Again it does not happen with versions 3.2.2.
> sample application
> Profiler results on application with Spring
> Profiler results on application without Spring

I think I've fixed the bug in SVN trunk if you want to try tomorrows
4.1-SNAPSHOT build it should now be resolved.



View raw message