So here's what's happening... There are actually three (3) connections being created:
1.. by your ProducerWithConsumer.java 1.. by the Spring DMLC 1.. by your explicit code in SpringConsumerWithReply (which you use to produce to the temp destination). So the connection that I saw laying around was not from the ProducerWithConsumer.java like I thought. That connection is cleaned up properly so no need for extra TCP socket monitors (although Gary's suggestion is always something to keep mind of... this can happen... it comes from this JIRA: https://issues.apache.org/jira/browse/AMQ-2006) But the connection for the *producer* in your SpringConsumerWithReply is kept open and that connection still has the reference to the TempQueue. This reference will be cleared when the producer goes away or if the producer sends another message. On Tue, Dec 11, 2012 at 7:44 AM, Gary Tully <gary.tu...@gmail.com> wrote: > 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 <christian.po...@gmail.com > >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 <cwik...@us.ibm.com> > 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 > -- *Christian Posta* http://www.christianposta.com/blog twitter: @christianposta
