activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Posta <>
Subject Re: Broker Leak
Date Mon, 10 Dec 2012 18:36:45 GMT
That could be the case. When a temp dest goes away, it's subs do not
automatically go away. This is something we've been discussing recently.
Can you post the configs you used in your test, or better yet a unit test
that shows this?

On Mon, Dec 10, 2012 at 7:44 AM, Jerry Cwiklik <> wrote:

> I am running AMQ broker v.5.6 on linux with 10G Xmx, 5G limit memoryUsage,
> producerFlowControl=false, no persistence, vmCursor and AUTO_ACKNOWLEDGE.
> There are a hundreds of producers and consumers, a few queues and a couple
> of hundred of temp queues. While watching broker memory in jConsole I
> notice
> a steady raise in OldGen. Forcing GC doesnt change anything. The broker
> eventually OOMs after a few days. The HeapAnalyzer shows 96% of heap in
> VmPendingMessageCursor. There are many messages destined for temp queues in
> this cursor.
> I created a simple test program where a Producer keeps sending messages to
> a
> Consumer which immediately sends a reply back to the Producer's temp queue.
> I kill the Producer with  -9, force GC on the broker and dump the heap.
> Looking at the heap, I can see that the VMPendingCursor holds messages for
> the temp queue which no longer exist! It looks to me that the broker never
> cleans up messages destined for temp queues which no longer exist leading
> to
> a memory leak. Attached is a snapshot from the heapAnalyzer showing a
> message in VMPendingMessageCursor.
> Is there a way to configure the broker to remove such messages? We
> currently
> dont expire messages (TTL=0). The broker knows when a temp queue is deleted
> so it should try to clean up messages associated with it.
> <>
> Regards, Jerry C
> --
> View this message in context:
> Sent from the ActiveMQ - User mailing list archive at

*Christian Posta*
twitter: @christianposta

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message