Uploaded image for project: 'Data Management'
  1. Data Management
  2. DM-1185

Channel was inactive for too long error

    Details

    • Type: Bug
    • Status: Won't Fix
    • Resolution: Done
    • Fix Version/s: None
    • Component/s: ctrl_events, Middleware
    • Labels:
      None

      Description

      There as an issue with the receiveEvent call that can cause an exception "Channel was inactive for too long".

      The fix for this (according to the ActiveMQ users list and archives) is to either completely disable the inactivity monitor or to increase the inactivity limit to something extremely high.

      The fix is adding: "wireFormat.maxInactivityDuration=0" to the URL in establishing the connection.

      There might also be a way of doing this directly in the ActiveMQ broker, but so far I haven't seen anything that would let me specify that.

        Attachments

          Activity

          spietrowicz Steve Pietrowicz created issue -
          spietrowicz Steve Pietrowicz made changes -
          Field Original Value New Value
          Epic Link DM-1121 [ 13930 ]
          spietrowicz Steve Pietrowicz made changes -
          Sprint W15 Dec Sprint 1 [ 113 ]
          spietrowicz Steve Pietrowicz made changes -
          Rank Ranked higher
          spietrowicz Steve Pietrowicz made changes -
          Story Points 2
          spietrowicz Steve Pietrowicz made changes -
          Rank Ranked higher
          Hide
          spietrowicz Steve Pietrowicz added a comment -

          This might actually be a feature instead of a bug. The normal situation for the ActiveMQ broker is to keep the connection alive which it has two threads monitoring. If no messages come through for a certain period of time, it sends a message to keep the channel active. In the situation where a connection is dropped, it wants to find out about this as soon a possible. After the timeout, the exception above is thrown. If it's set to zero, that exception wouldn't be thrown. (At least, I believe that's what would happen). I'm checking with the activemq mailing list about this.

          Show
          spietrowicz Steve Pietrowicz added a comment - This might actually be a feature instead of a bug. The normal situation for the ActiveMQ broker is to keep the connection alive which it has two threads monitoring. If no messages come through for a certain period of time, it sends a message to keep the channel active. In the situation where a connection is dropped, it wants to find out about this as soon a possible. After the timeout, the exception above is thrown. If it's set to zero, that exception wouldn't be thrown. (At least, I believe that's what would happen). I'm checking with the activemq mailing list about this.
          spietrowicz Steve Pietrowicz made changes -
          Status To Do [ 10001 ] In Progress [ 3 ]
          spietrowicz Steve Pietrowicz made changes -
          Story Points 2 1
          Hide
          spietrowicz Steve Pietrowicz added a comment -

          From the mailing list:

          Setting maxInactivityDuration to 0 disables the activity monitor. The
          advantages include reducing the overhead when there are large numbers of
          idle connections, and eliminating forced disconnects on slow connections
          that are otherwise active.

          These seem like minor advantages. The overhead is really low, and can be
          reduced by increasing the inactivity duration. And it is valuable to
          disconnect connections that are really inactive.

          Note that - just because there is a setting, doesn't mean there's really a
          "good" reason to use it. Often settings are added as a means to try
          different approaches, or to allow for backward compatibility when new
          features are added. They may even be only useful when troubleshooting a
          problem.

          Hope this helps.

          and

          As Art says, the advantages are minor, and the disadvantages (such as the
          inability to detect disconnections due to network problems) are not. So
          your default should be to use a non-zero value unless you come up with a
          clear reason why you think a value of zero would be better for you, and
          clearly you don't have one of those at the moment.

          If you start getting the "Channel was inactive for too long" log lines
          regularly, then you'll need to investigate what's going on in your network
          or on your brokers to figure out why keep-alives aren't making it to their
          destinations in time. Contrary to whatever you may have read, the solution
          to seeing those log lines is to figure out what's going wrong to cause them
          in the first place, not to turn them off and assume that everything's
          fine. But only if you're seeing them regularly; if you saw this once a
          long time ago, I wouldn't worry about it – once in a blue moon is probably
          just a network hiccup, and you only need to worry about it when it becomes
          a pattern.

          Tim

          I've only seen this one time, and it was around the time I was seeing strange network behavior that turned out to be duplicate ethernet and IP addresses on a duplicate VM. I'm going to close this based on the recommendations above. If it becomes a problem in the future, it will be investigated.

          Show
          spietrowicz Steve Pietrowicz added a comment - From the mailing list: Setting maxInactivityDuration to 0 disables the activity monitor. The advantages include reducing the overhead when there are large numbers of idle connections, and eliminating forced disconnects on slow connections that are otherwise active. These seem like minor advantages. The overhead is really low, and can be reduced by increasing the inactivity duration. And it is valuable to disconnect connections that are really inactive. Note that - just because there is a setting, doesn't mean there's really a "good" reason to use it. Often settings are added as a means to try different approaches, or to allow for backward compatibility when new features are added. They may even be only useful when troubleshooting a problem. Hope this helps. and As Art says, the advantages are minor, and the disadvantages (such as the inability to detect disconnections due to network problems) are not. So your default should be to use a non-zero value unless you come up with a clear reason why you think a value of zero would be better for you, and clearly you don't have one of those at the moment. If you start getting the "Channel was inactive for too long" log lines regularly, then you'll need to investigate what's going on in your network or on your brokers to figure out why keep-alives aren't making it to their destinations in time. Contrary to whatever you may have read, the solution to seeing those log lines is to figure out what's going wrong to cause them in the first place, not to turn them off and assume that everything's fine. But only if you're seeing them regularly; if you saw this once a long time ago, I wouldn't worry about it – once in a blue moon is probably just a network hiccup, and you only need to worry about it when it becomes a pattern. Tim I've only seen this one time, and it was around the time I was seeing strange network behavior that turned out to be duplicate ethernet and IP addresses on a duplicate VM. I'm going to close this based on the recommendations above. If it becomes a problem in the future, it will be investigated.
          spietrowicz Steve Pietrowicz made changes -
          Resolution Done [ 10000 ]
          Status In Progress [ 3 ] Won't Fix [ 10405 ]
          spietrowicz Steve Pietrowicz made changes -
          Story Points 1 2
          jbecla Jacek Becla made changes -
          Team Process Middleware [ 10206 ]
          frossie Frossie Economou made changes -
          Team Process Middleware [ 10206 ] Data Facility [ 12219 ]

            People

            • Assignee:
              spietrowicz Steve Pietrowicz
              Reporter:
              spietrowicz Steve Pietrowicz
              Watchers:
              Steve Pietrowicz
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Summary Panel