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$AcceptingThread.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

Reply via email to