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 18:13:00 GMT
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.tully@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.posta@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 <cwiklik@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

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