[
https://issues.apache.org/activemq/browse/AMQ-1146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manuel Teira reopened AMQ-1146:
-------------------------------
After discussing the problem with Rob Davies in the IRC channel, I'm reopening
this issue to rollback the synchronization for the readCheck/writeCheck.
> InactivityMonitor: Transport connection disconnected "Channel was inactive
> for too long."
> -----------------------------------------------------------------------------------------
>
> Key: AMQ-1146
> URL: https://issues.apache.org/activemq/browse/AMQ-1146
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 4.1.0
> Environment: Windows Server 2003 running broker and Windows XP
> running client. Java 1.5.0_08
> Reporter: Mari
> Assignee: Hiram Chirino
> Priority: Minor
> Fix For: 5.0.0
>
> Attachments: InactivityMonitor_changed.java,
> InactivityMonitor_Original.java
>
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> Sometimes (when the transport is idle for long) the transport gets
> disconnected with the message "Channel was inactive for too long."
> Apparently this is same as reported in
> http://www.nabble.com/Channel-was-inactive-for-too-long-t1463069.html#a3971744
> and
> http://www.nabble.com/Durable-consumer-reconnect-problem-tf1716817.html#a6147014
>
> Version: 4.1
> Background:
> The class org.apache.activemq.transport.InactivityMonitor runs
> monitoring threads to check the read and write of the transport(TCP for
> example). If it hasn't sent the message during the given period, it sends a
> KeepAliveInfo to ensure the connectivity. If it doesn't receive the message
> for a given duration, then it disconnects the transport.
> By default, the maximumInactivityDuration is 30000 milliseconds. This
> is the time interval between the check for read. That is if an end of the
> transport doesn't receive any message for this period, then it will close the
> connection. For the read check, the time interval is half of
> maximumInactivityDuration i.e. 15000 millisecond. That is if a message was
> not sent during this period, it will send a KeepAliveInfo to ensure the
> connectivity.
> Problem and the recommended fix:
> The InactivityMonitor class uses the flags inReceive and
> commandReceived variables in methods readCheck and onCommand. Typically these
> two methods are called from different threads. Also, the flags inSend and
> commandSent are used in methods oneway and writeCheck. Again these two
> methods are called from different threads. But, the synchronization was
> missing for these. This seems to be a potential cause for the problem. So,
> synchronization has been incorporated for these flag usages.
> The same class InactivityMonitor is used at both client and server
> side. In general, the write check (which sends KeepAliveInfo) happens twice
> during the time when the read check happens once. Probably the client and
> server machines have performance differences and just to be safer, now the
> write check is made to happen thrice during the time when the read check
> happens once.
> The original and the changed source files are attached here.
> http://www.nabble.com/file/5958/InactivityMonitor_changed.java
> http://www.nabble.com/file/5957/InactivityMonitor_Original.java
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
