<div class="wiki-content maincontent"><h1>ActiveMQ InactivityMonitor</h1><p>The ActiveMQ InactivityMonitor is an active thread that checks the connection is still active and if it suspects the connection is not functioning correctly, it closes the connection.</p><p>Connections are monitored by:</p><ul><li>Ensuring data is read from the connection during the specified time period (Max Inactivity Duration).</li><li>Writing a&#160;<strong><code>KeepAliveInfo</code></strong> message to the connection if no <strong>normal</strong> activemq traffic is sent across the connection during the specified time period.</li></ul><p>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 <strong>normal</strong> ActiveMQ traffic has not been sent across the connection during that period, it expects to receive a&#160;<strong><code>KeepAliveInfo</code></strong> message sent by the InactivityMonitor on the other end of the connection.</p><p>Using the default values; if no data has been written or read from the connection for 30 seconds, the InactivityMonitor kicks in. The InactivityMonitor throws an&#160;<strong><code>InactivityIOException</code></strong> and shuts down the transport associated with the connection. This results in the following&#160;<strong><code>DEBUG</code></strong> logging:</p><structured-macro ac:macro-id="db114f31-fb57-4d2d-8f2d-390f5a254728" ac:name="noformat" ac:schema-version="1"><plain-text-body>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 (&gt;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 (&gt;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)
</plain-text-body></structured-macro><h3>Advanced InactivityMonitor Configuration</h3><p>There are some configuration options to further fine tune the <code>InactivityMonitor</code>. Note, for most use cases the default values are just fine.</p><table><tbody><tr><th colspan="1" rowspan="1">Parameter</th><th colspan="1" rowspan="1">Default Value</th><th colspan="1" rowspan="1">Description</th></tr><tr><td colspan="1" rowspan="1"><p><code>wireFormat.maxInactivityDuration</code></p></td><td colspan="1" rowspan="1"><p><code>30000</code></p></td><td colspan="1" rowspan="1"><p>Timeout, in milliseconds, after which the connection is closed by the broker if no data has been received.</p></td></tr><tr><td colspan="1" rowspan="1"><p><code>wireFormat.maxInactivityDurationInitalDelay</code></p></td><td colspan="1" rowspan="1"><p><code>10000</code></p></td><td colspan="1" rowspan="1"><p>Specifies the maximum delay, in milliseconds, before connection inactivity monitoring is started.</p><p>This can prove useful if a broker is under load with many connections being created concurrently.</p></td></tr><tr><td colspan="1" rowspan="1"><p><code>transport.useInactivityMonitor</code></p></td><td colspan="1" rowspan="1"><p><code>true</code></p></td><td colspan="1" rowspan="1"><p>A value of&#160;<strong><code>false</code></strong> disables the&#160;<code>InactivityMonitor</code> completely and connections will never time out.</p></td></tr><tr><td colspan="1" rowspan="1"><p><code>transport.useKeepAlive</code></p></td><td colspan="1" rowspan="1"><p><code>true</code></p></td><td colspan="1" rowspan="1"><p>Determines if a&#160;<strong><code>KeepAliveInfo</code></strong> message should be sent on an idle connection to prevent it from timing out.</p><p>Disabling the keep alive will still make connections time out when no data was received on the connection for the specified amount of time.</p></td></tr></tbody></table><p>&#160;</p><p>These parameters can be specified directly on the client side connection URL, e.g. <strong><code>tcp://localhost:61616?wireFormat.maxInactivityDuration=30000</code>, </strong>or on the broker's transport connector URL:</p><structured-macro ac:macro-id="71606cd5-86b4-43fd-b0e4-3a4b7af305b4" ac:name="code" ac:schema-version="1"><parameter ac:name="language">xml</parameter><plain-text-body>&lt;transportConnectors&gt;
  &lt;transportConnector name="openwire" uri="tcp://0.0.0.0:61616?wireFormat.maxInactivityDuration=30000&amp;amp;wireFormat.maxInactivityDurationInitalDelay=10000"/&gt;
&lt;/transportConnectors&gt;
</plain-text-body></structured-macro><h3>What happens if the&#160;<code>maxInactivityDuration</code> and <code>maxInactivityDurationInitalDelay</code> are set to different values on either side of the same connection?</h3><p>At startup the InactivityMonitor negotiates the appropriate&#160;<strong><code>maxInactivityDuration</code></strong> and&#160;<strong><code>maxInactivityDurationInitalDelay</code></strong>. The shortest duration is taken for the connection.</p><h3>Can the InactivityMonitor on a connection be disabled?</h3><p>Setting <strong><code>transport.useInactivityMonitor=false</code></strong> will disable the InactivityMonitor<strong>. </strong>Configuring <strong><code>wireFormat.maxInactivityDuration=0</code></strong> will achieve the same result.</p><h3>Potential Issues</h3><p><link><page ri:content-title="Slow networks drop large messages"></page><plain-text-link-body>slow-networks-drop-large-messages</plain-text-link-body></link></p><p>&#160;</p></div>