you are looking at the need for a writeTimeoutFilter or inactivityMonitor or OS level tcp keepAlive to detect a half closed socket as the result of an abortive close of the client.
On 11 December 2012 14:36, Christian Posta <[email protected]>wrote: > I just ran your tests. > Actually, this doesn't seem to be the case of the consumers not going away. > Looks like the connection wasn't properly cleaned up on the broker's side > after the kill -9. Let me try with the trunk and see if there's anything > different before I dig deeper to see why it wasn't cleaned up. > > > On Mon, Dec 10, 2012 at 2:37 PM, Jerry Cwiklik <[email protected]> wrote: > > > Thanks, so if the subs dont go away the broker thinks it can deliver the > > messages to them even though the destination is gone? Seems that a temp > > queue removal should result/trigger a cleanup of messages associated with > > that destination. > > > > I dont have JUnit test. Instead, I attach sources for a simple jms > producer > > and a consumer which I ran as separate processes. While the producer is > > blasting msgs I kill it with -9, force the GC in the broker's jvm via > > jConsole and dump the heap to analyze. I ran this scenario multiple times > > and am seeing dead messages in a VM cursor. > > > > ProducerWithConsumer.java > > < > > > http://activemq.2283324.n4.nabble.com/file/n4660465/ProducerWithConsumer.java > > > > > SpringConsumerWithReply.java > > < > > > http://activemq.2283324.n4.nabble.com/file/n4660465/SpringConsumerWithReply.java > > > > > Thanks, Jerry C > > > > > > > > > > -- > > View this message in context: > > http://activemq.2283324.n4.nabble.com/Broker-Leak-tp4660437p4660465.html > > Sent from the ActiveMQ - User mailing list archive at Nabble.com. > > > > > > -- > *Christian Posta* > http://www.christianposta.com/blog > twitter: @christianposta > -- http://redhat.com http://blog.garytully.com
