The request for inclusion in 0.20 was approved so I have just merged the change to the release branch, it will be included in RC2.
Robbie On 4 December 2012 17:54, Marco Helmich <[email protected]> wrote: > > Hi Robbie, > thanks for the quickly turnaround!!!I will keep an eye on the JIRA case. > > Cheers, Marco > -----Original Message-----From: Robbie Gemmell [mailto: > [email protected]] Sent: Monday, December 03, 2012 3:10 PMTo: > [email protected]: Re: Java broker crashes due to misbehaving > client > Hi Marco, > This is a defect, the broker does detect the closed connection but is then > failing to clear it down fully. > I have raised https://issues.apache.org/jira/browse/QPID-4489 to cover > resolving the issue and have made an initial commit with a fix. If it > passes review I will request its inclusion in 0.20, which hit RC1 earlier > today, although its then up to the release managers discretion. The patch > is quite isolated and I expect it should work with prior releases if you > wanted to try. > Regarding monitoring, users I deal with typically monitor activity via the > JMX interface, and/or use message clients that do something with the broker > to check it is operational. > Robbie > > On 3 December 2012 18:27, Marco Helmich <[email protected]> wrote: > >> Hi,> we are using qpid (v0.16) successfully since quite some time as > part > of our infrastructure.Another part of our infrastructure is a > > monitoring service which periodically connects to the broker on the > qmqp > port (plain tcp connection) and closes the connection immediately > after > connecting. It does that in order to make sure the service is up and > running.> After running this monitoring service a while we receive OOMs > (saying > that the JVM ran out of threads).Uncaught exception, shutting > down.> java.lang.OutOfMemoryError: unable to create new native thread > at> java.lang.Thread.start0(Native Method) at> > java.lang.Thread.start(Thread.java:597) at> > org.apache.qpid.transport.network.io.IoSender.initiate(IoSender.java:97)> > at> > org.apache.qpid.transport.network.io.IoNetworkConnection.start(IoNetworkConnection.java:58)> > at> > org.apache.qpid.transport.network.io.IoNetworkTransport$AcceptingThrea> > d.run(IoNetworkTransport.java:225)>> Turns out this monitoring service > doesn't follow the amq protocol > which creates a thread leak in the broker > (IOSender threads keep > lingering around).> I'm aware that this client > doesn't behave according to the amq > protocol but the other side of the > story is that a misbehaving client > (reliably and quickly is able to bring > down the service). I noticed > other queueing products have the same > issue.So my question is: Is > there a reason the broker doesn't detect > closed client connections and > guards itself from a DoS?> Out of > curiosity: What do other people use to check the availibility > of the > service? We fell back to pinging the JMX port for now but are > open to > other solutions.>>> Cheers, Marco >
