activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Posta <christian.po...@gmail.com>
Subject Re: Broker Leak
Date Tue, 11 Dec 2012 22:41:22 GMT
No, that's not expected behavior. I ran your tests as you described and I
do see memory being consumed and churned, but it all eventually gets
collected by the GC.

Is your heap the 10G heap you mentioned originally? If you can get me the
heapdump, I'll gladly take a look for you. Let me know and I can set up a
share somehwere.


On Tue, Dec 11, 2012 at 1:32 PM, Jerry Cwiklik <cwiklik@us.ibm.com> wrote:

> Thanks, your reply seems consistent with what I am seeing in the heap dump
> (see heapAnalyzer screenshot attached to the initial post). I am still
> unclear how are the dead messages cleaned up (if ever). I ran a new
> scenario
> where I had 4 SpringConsumerWithReply processes and a single
> ProducerWithReply process which I start in a shell's endless for-loop.
> for i in (1 .. 1000000000)
> do
>    java -jar producer-w-consumer.jar tcp://0.0.0.0:61616 serviceQ 100000
> 500000
> done
>
> I run the script and keep killing ProducerWithReply process which gets
> launched again. I dont touch any of the SpringConsumerWithReply processes.
> After a short while the broker OOMs.
>
> Given the above scenario, is it expected that the broker OOMs? I know that
> it OOMs due to messages destined for temp queues which no longer exist. How
> should the ProducerExchange instances be cleaned up? Should the
> SpringConsumerWithRep close a Session or Connection to a destination that
> it
> thinks is no longer used? Is closing the Session enough to purge
> ProducerExchange from the broker?
>
> -Jerry C
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Broker-Leak-tp4660437p4660513.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>



-- 
*Christian Posta*
http://www.christianposta.com/blog
twitter: @christianposta

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