Potential memory leak in client lib

[springusr]

I did a quick test where I sent like 5k messages , I can see spike heap and here is what thread dump. Below some detail from thread dump tool. I am using client lib version 4.0

One instance of "com.rabbitmq.client.impl.recovery.AutorecoveringConnection" loaded by "org.springframework.boot.loader.LaunchedURLClassLoader @ 0xa0041fd8" occupies 13,735,416 (14.08%) bytes. The memory is accumulated in one instance of "java.util.concurrent.ConcurrentHashMap$Node[]" loaded by "<system class loader>".

Keywords
java.util.concurrent.ConcurrentHashMap$Node[]
org.springframework.boot.loader.LaunchedURLClassLoader @ 0xa0041fd8
com.rabbitmq.client.impl.recovery.AutorecoveringConnection

[Michael Klishin]

This is not an evidence of a memory leak. We cannot suggest much without seeing your code. 

On 25 January 2017 at 01:46:25, springusr (patelm...@gmail.com) wrote:
> I did a quick test where I sent like 5k messages , I can see spike heap and
> here is what thread dump. Below some detail from thread dump tool. I am
> using client lib version 4.0
>
> One instance of

> *"com.rabbitmq.client.impl.recovery.AutorecoveringConnection"* loaded by *"org.springframework.boot.loader.LaunchedURLClassLoader
> @ 0xa0041fd8"* occupies *13,735,416 (14.08%)* bytes. The memory is

> accumulated in one instance of

> *"java.util.concurrent.ConcurrentHashMap$Node[]"* loaded by *"> loader>"*.
>
> *Keywords*

> java.util.concurrent.ConcurrentHashMap$Node[]
> org.springframework.boot.loader.LaunchedURLClassLoader @ 0xa0041fd8
> com.rabbitmq.client.impl.recovery.AutorecoveringConnection
>
>
>
>
>
>

> --
> You received this message because you are subscribed to the Google Groups "rabbitmq-users"
> group.
> To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
> To post to this group, send an email to rabbitm...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

--
MK

Staff Software Engineer, Pivotal/RabbitMQ

[Michael Klishin]

The only field in AutorecoveringConnection of type ConcurrentHashMap is
a map of channels that must be kept track of for them to be recovered:
https://github.com/rabbitmq/rabbitmq-java-client/blob/master/src/main/java/com/rabbitmq/client/impl/recovery/AutorecoveringConnection.java#L90

I suspect that you code opens a new channel per message or something like that.
It's not necessary, channels can be long lived.

~ 14 MB of heap is hardly a reason for concern.

On 25 January 2017 at 01:46:25, springusr (patelm...@gmail.com) wrote:

> I did a quick test where I sent like 5k messages , I can see spike heap and
> here is what thread dump. Below some detail from thread dump tool. I am
> using client lib version 4.0
>
> One instance of

> *"com.rabbitmq.client.impl.recovery.AutorecoveringConnection"* loaded by *"org.springframework.boot.loader.LaunchedURLClassLoader

> @ 0xa0041fd8"* occupies *13,735,416 (14.08%)* bytes. The memory is

> accumulated in one instance of

> *"java.util.concurrent.ConcurrentHashMap$Node[]"* loaded by *"> loader>"*.
>
> *Keywords*

> java.util.concurrent.ConcurrentHashMap$Node[]
> org.springframework.boot.loader.LaunchedURLClassLoader @ 0xa0041fd8
> com.rabbitmq.client.impl.recovery.AutorecoveringConnection
>
>
>
>
>
>

[Miral Patel]

Thank Mike for quick response. Few points on that:

- I use rabbit template so I don't have to mess with those channels business.

- In my test I had 10 threads running same time using same rabbit template object to send messages continuous. How this is supposed to be handled now in terms of channels and auto recovery with rabbit template.

- after I ran test I saw spike on heap, so I used spring boot actuator endpoint to get heapdump, I believe it will scan just part of heap to get us suspects of memory leak (prob that is why we see 14mb). And this was one of it.

- my code is very simple, it just used rabbit template and send messages.

And yes this may or may not be memory issue, more testing will be required.

On Jan 24, 2017 4:51 PM, "Michael Klishin" <mkli...@pivotal.io> wrote:

The only field in AutorecoveringConnection of type ConcurrentHashMap is
a map of channels that must be kept track of for them to be recovered:
https://github.com/rabbitmq/rabbitmq-java-client/blob/master/src/main/java/com/rabbitmq/client/impl/recovery/AutorecoveringConnection.java#L90

I suspect that you code opens a new channel per message or something like that.
It's not necessary, channels can be long lived.

~ 14 MB of heap is hardly a reason for concern.

On 25 January 2017 at 01:46:25, springusr (patelm...@gmail.com) wrote:
> I did a quick test where I sent like 5k messages , I can see spike heap and
> here is what thread dump. Below some detail from thread dump tool. I am
> using client lib version 4.0
>
> One instance of
> *"com.rabbitmq.client.impl.recovery.AutorecoveringConnection"* loaded by *"org.springframework.boot.loader.LaunchedURLClassLoader
> @ 0xa0041fd8"* occupies *13,735,416 (14.08%)* bytes. The memory is
> accumulated in one instance of
> *"java.util.concurrent.ConcurrentHashMap$Node[]"* loaded by *"> loader>"*.
>
> *Keywords*
> java.util.concurrent.ConcurrentHashMap$Node[]
> org.springframework.boot.loader.LaunchedURLClassLoader @ 0xa0041fd8
> com.rabbitmq.client.impl.recovery.AutorecoveringConnection
>
>
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "rabbitmq-users"
> group.

> To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-users+unsubscribe@googlegroups.com.
> To post to this group, send an email to rabbitmq-users@googlegroups.com.

[Michael Klishin]

If you want to reason about what consumes memory, yes, you do.
RabbitTemplate maintains a cache of channels IIRC, for example.

At 14 MB of heap that's hardly justified, however. Some applications consume much more
without having a single connection open.

> > an email to rabbitmq-user...@googlegroups.com.
> > > To post to this group, send an email to rabbitm...@googlegroups.com.