ActiveMQ
  1. ActiveMQ
  2. AMQ-1146

InactivityMonitor: Transport connection disconnected "Channel was inactive for too long."

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 4.1.0
    • Fix Version/s: 5.0.0
    • Component/s: Broker
    • Labels:
      None
    • Environment:

      Windows Server 2003 running broker and Windows XP running client. Java 1.5.0_08

    • Patch Info:
      Patch Available

      Description

      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

        Activity

        Mari created issue -
        Rob Davies made changes -
        Field Original Value New Value
        Assignee Hiram Chirino [ chirino ]
        james strachan made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Fix Version/s 5.0.0 [ 11712 ]
        Resolution Fixed [ 1 ]
        Manuel Teira made changes -
        Status Resolved [ 5 ] Reopened [ 4 ]
        Resolution Fixed [ 1 ]
        Hiram Chirino made changes -
        Resolution Fixed [ 1 ]
        Status Reopened [ 4 ] Resolved [ 5 ]
        Jeff Turner made changes -
        Project Import Fri Nov 26 22:32:02 EST 2010 [ 1290828722158 ]

          People

          • Assignee:
            Hiram Chirino
            Reporter:
            Mari
          • Votes:
            2 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 1h
              1h
              Remaining:
              Remaining Estimate - 1h
              1h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development