activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Bain <>
Subject Re: MQTT Subscriber gets disconnected frequently when there are large number of MQTT clients connected
Date Tue, 31 Oct 2017 12:49:44 GMT
OK. Those log lines indicate that the far side of the connection (the
client) closed the connection when the near end (the broker) wasn't
expecting it. The root cause may be something on the broker's side (for
example, the broker got so busy that it stopped responding to the client,
who reacted by closing the connection), but for now we need to follow the
trail over to the client side and see what its logs say. Can you please
post whatever content is in the client logs shortly before you see the
content you posted from the broker's logs?

Generic reasons why the broker could become unresponsive include not having
enough heap (so the JVM spends most of its time GCing), having so many
connections that it can't service them all quickly enough, disk I/O that's
too slow, or of course maybe there's a bug. Some of those (e.g. spending
too much time GCing) manifest as high CPU usage, and you said CPU usage is
low/normal, but you may still want to double check GC and CPU usage from
JConsole or something similar.

You could also take a thread dump (via jstack or another method, there are
several ways to do this) of your production broker and see if maybe there
are lots of threads blocked waiting for a lock while trying to do real work
(i.e. not the threads in a thread pool that are blocked trying to get a
task from their queue, those are expected and don't indicate a problem).


On Oct 29, 2017 11:21 PM, "Shobhana" <> wrote:

> Hi Tim,
> The log content quoted in my post was from broker log.
> I'll try to reproduce this in a test environment. Meanwhile if you could
> think of any common (generic) reasons why broker may becomes unresponsive,
> please share.
> Thanks,
> Shobhana
> --
> Sent from:
> f2341805.html

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