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). Tim On Oct 29, 2017 11:21 PM, "Shobhana" <shobh...@quickride.in> 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: http://activemq.2283324.n4.nabble.com/ActiveMQ-User- > f2341805.html >
