[rabbitmq-discuss] RabbitMQ Java Client - Defect 24723 - Memory leak

Steve Powell steve at rabbitmq.com
Mon Apr 2 16:13:10 BST 2012


Hi Scott,

The original problem was due to the failure of the Java client to free
up the resources associated with the Consumer callbacks on a channel.

This was fixed by putting in a clean-up call (in
handleShutdownSignal()); but it is just possible that this is not being
called in some circumstances.

Can you tell us more about how the channels are being closed? How many
channels are created for the messages you are sending in the
sustainability tests?

In the bug you cite, the reported used the following mechanism to
analyse the memory usage:

Get process id <pid> and do the following:

 jmap -dump:format=b,file=yo.bin <pid>
 jhat jhat -J-mx768m -stack false yo.bin

Once jhat brings up http server, go here:

 http://localhost:7000/showInstanceCounts/

The original problem was the WorkPool object holding on to all the
channels after they were closed. This looks extremely similar, but the
bug was fixed in 2.7.1, so you may have found a bug in the fix.

Steve Powell  (a silly bunny)
----------some more definitions from the SPD----------
chinchilla (n.) Cooling device for the lower jaw.
socialcast (n.) Someone to whom everyone is speaking but nobody likes.
literacy (n.) A textually transmitted disease usually contracted in childhood.

On 28 Mar 2012, at 20:21, Scott Garten wrote:

> Hi all,
>  
> This morning started out with an OutOfMemory exception after I kicked off a sustainability test before I left the office for the day; digging into it we found a number of classes failing to free up. They appear to correlate to the number of messages that we sent to rabbitmq. A web search revealed a defect # 24723 was identified and reported fixed.
>  
> We were using 2.7.1 of the Java client, but since have also tried 2.8.0 and 2.8.1 of the client – hoping that one of these later releases contained a fix. Unfortunately, we are still seeing the same memory leak behavior.
>  
> Here is a jmap dump of the classes that we witness not freeing (even after an explicit GC).
>  
>   19:          1979         189984  com.rabbitmq.client.impl.ChannelN
>   28:          1980          79200  com.rabbitmq.client.impl.CommandAssembler
>   29:          1979          79160  com.rabbitmq.client.ShutdownSignalException
>   30:          1979          79160  com.rabbitmq.client.impl.ConsumerDispatcher
>   35:          1979          63328  com.rabbitmq.client.impl.AMQImpl$Channel$Close
>   48:          1980          31680  com.rabbitmq.client.impl.AMQCommand
>  
> Appears to be similar to that which was previously reported on the mailing list.
>  
> Not certain where to turn at this point. Can anyone confirm that they see the fix freeing up the objects?
>  
> Thanks, Scott.
> 
> 
> ====================
> The information contained in this transmission is confidential. It is intended solely for the use of the individual(s) or organization(s) to whom it is addressed. Any disclosure, copying or further distribution is not permitted unless such privilege is explicitly granted in writing by Purchasing Power LLC. Furthermore, Purchasing Power LLC.. is not responsible for the proper and complete transmission of the substance of this communication, nor for any delay in its receipt. 
> ----------------------------------------------------- 
> All outgoing emails are scanned for viruses by Barracuda Spam Firewall   ­­  _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss



More information about the rabbitmq-discuss mailing list