You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by "Anuj Khandelwal (JIRA)" <ji...@apache.org> on 2013/12/26 10:05:51 UTC
[jira] [Updated] (AMQ-4956) Hung ActiveMQ broker and processes are
blocking
[ https://issues.apache.org/jira/browse/AMQ-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Anuj Khandelwal updated AMQ-4956:
---------------------------------
Attachment: JStack.txt
> Hung ActiveMQ broker and processes are blocking
> -----------------------------------------------
>
> Key: AMQ-4956
> URL: https://issues.apache.org/jira/browse/AMQ-4956
> Project: ActiveMQ
> Issue Type: Bug
> Affects Versions: 5.8.0
> Reporter: Anuj Khandelwal
> Attachments: JStack.txt
>
>
> Hi,
> I am using ActiveMQv5.8. Yesterday I saw some weird issue happening with broker where:
> ActiveMQ broker running on cluster machine was in hung state and not responding to the client request. It was blocking processes. Also there are lots of connection from a single client (more than 100)
> I took jstack on the hung process. Attaching the same with this request. Many of the blocked threads indicate that they were doing some inactivity monitoring related processing.
> I am seeing lot of warning in my broker log related to Inactivity monitoring:
> ""
> [20131214 01:14:37:740 IST (ActiveMQ InactivityMonitor Worker) org.apache.activemq.broker.TransportConnection#serviceTransportException 238 WARN] - Transport Connection to: tcp://*.*.*.*:1373 failed: org.apache.activemq.transport.InactivityIOException: Channel was inactive for too (>30000) long: tcp://*.*.*.*:21373
> ""
> My Observations:
> I suspect that the ActiveMQ broker is not handling momentary cpu spikes very well -- it goes into a state where messages get piled up and
> expensive protocols like closing/reopening all connections are triggered due to heartbeat timeouts from clients. The current heartbeat/inactivity timeout is 30 seconds which may be too low when handing more than 250 clients.
> Please help me to understand and handle this issue because it is affecting the critical production environment.
> I don't know how to handle this and what to do but I think I should provide Inactivity timeout period is 120 seconds which is enough time to do the read check. So Are there any side effects of this Inactivity monitoring time increase ?
> Thanks,
> Anuj
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)