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
