Fuse MB: How does the InactivityMonitor work?

Solution Verified - Updated -

Environment

  • Fuse Message Broker/ActiveMQ
    • 5.5.1
  • Red Hat JBoss Fuse
    • 6.x

Issue

  • ActiveMQ: How does the Inactivity Monitor work?

  • we see a regular AbstractInactivityMonitor log entry

Resolution

The ActiveMQ InactivityMonitor checks the connection is still active and if it suspects the connection is not functioning correctly, it closes the connection.

Connections are monitored by:

  • ensuring data is read from the connection during the specified time period (Max Inactivity Duration).

  • writing a KeepAliveInfo message to the connection if no normal activemq traffic is sent across the connection during the specified time period.

Each connection has two InactivityMonitors associated, one on each end of the connection. The InactivityMonitor expects to receive data on the connection during a specified time period. If normal activemq traffic has not been sent across the connection during that period, it expects to receive a KeepAliveInfo message sent by the InactivityMonitor on the other end of the connection.

Using the default values; if no data has been read from the connection for 30 seconds the InactivityMonitor assumes there is an issue with the connection. The InactivityMonitor throws an InactivityIOException and shuts down the transport associated with the connection. This results in the following DEBUG logging:


2012-06-26 17:13:55,712 | DEBUG | 30000 ms elapsed since last read check. | org.apache.activemq.transport.AbstractInactivityMonitor | InactivityMonitor ReadCheck
2012-06-26 17:13:55,712 | DEBUG | No message received since last read check for tcp:///127.0.0.1:52659! Throwing InactivityIOException. | org.apache.activemq.transport.AbstractInactivityMonitor | InactivityMonitor ReadCheck
2012-06-26 17:13:55,714 | DEBUG | Transport Connection to: tcp://127.0.0.1:52659 failed: org.apache.activemq.transport.InactivityIOException: Channel was inactive for too (>30000) long: tcp://127.0.0.1:52659 | org.apache.activemq.broker.TransportConnection.Transport | InactivityMonitor Async Task: java.util.concurrent.ThreadPoolExecutor$Worker@6a346239
org.apache.activemq.transport.InactivityIOException: Channel was inactive for too (>30000) long: tcp://127.0.0.1:52659
    at org.apache.activemq.transport.AbstractInactivityMonitor$4.run(AbstractInactivityMonitor.java:187)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:680)

How to specify the max inactivity duration?

The max inactivity duration can be set by specifying the wireFormat.maxInactivityDuration attribute in the connection URL:


tcp://localhost:61616?wireFormat.maxInactivityDuration=30000

This attribute is valid for both the broker's transport connector URL and the client side connection URL. Default value is 30000 milliseconds.

What happens if the maxInactivityDuration is set to different values on either side of the same connection?

At startup the InactivityMonitor negotiates the appropriate maxInactivityDuration. The shortest duration is taken as the maxInactivityDuration for the connection.

Can the InactivityMonitor on a connection be disabled?

Setting wireFormat.maxInactivityDuration=0 will disable the InactivityMonitor

What is wireFormat.maxInactivityDurationInitalDelay ?

wireFormat.maxInactivityDurationInitalDelay is used to specify the maximum delay before inactivity monitoring is started on the connection. It can be useful if a broker is under load with many connections being created concurrently.

Potential issues to be aware of:

http://activemq.apache.org/slow-networks-drop-large-messages.html

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

Comments