Environment & versions:
==== Activemq:
5.3.2
==== OS:
RHEL5 (Linux xxx.yyy.zzz 2.6.18-238.1.1.el5 #1 SMP Tue Jan 4
13:32:19 EST 2011 x86_64 x86_64 x86_64 GNU/Linux)
==== Java (both on the apps- and activemq- side):
java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02, mixed mode)
The activemq configuration is the out-of-the-box one without any tweaks.
The clients connect on the tcp transport. Here's the relevant config
snippet from the broker's activemq.xml:
<transportConnectors>
<transportConnector name="openwire" uri="tcp://0.0.0.0:61616"/>
</transportConnectors>
The producers and consumers on the activemq managed queues (Java
applications running within JBoss) use "tcp://x.x.x.x:61616" as the JMS
destination JNDI URL to open JMS connections.
Usually on a Monday after no activity during the weekend we see the
following exceptions when we try to run things in the environment:
javax.jms.JMSException: Channel was inactive for too long:
tlcvmq01/x.x.x.x:61616
at
org.apache.activemq.util.JMSExceptionSupport.create(JMSExceptionSupport.
java:62)
at
org.apache.activemq.ActiveMQConnection.doAsyncSendPacket(ActiveMQConnect
ion.java:1245)
at
org.apache.activemq.ActiveMQConnection.asyncSendPacket(ActiveMQConnectio
n.java:1237)
at
org.apache.activemq.ActiveMQSession.asyncSendPacket(ActiveMQSession.java
:1857)
at
org.apache.activemq.ActiveMQMessageConsumer.doClose(ActiveMQMessageConsu
mer.java:654)
at
org.apache.activemq.ActiveMQMessageConsumer.close(ActiveMQMessageConsume
r.java:645)
at
com.hmsonline.cvutils.workdistribution.JmsThreadedConsumer.run(JmsThread
edConsumer.java:116)
at java.lang.Thread.run(Thread.java:619)
Caused by: org.apache.activemq.transport.InactivityIOException: Channel
was inactive for too long: tlcvmq01/x.x.x.x:61616
at
org.apache.activemq.transport.InactivityMonitor.oneway(InactivityMonitor
.java:235)
at
org.apache.activemq.transport.TransportFilter.oneway(TransportFilter.jav
a:83)
at
org.apache.activemq.transport.WireFormatNegotiator.oneway(WireFormatNego
tiator.java:104)
at
org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:
40)
at
org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelat
or.java:60)
at
org.apache.activemq.ActiveMQConnection.doAsyncSendPacket(ActiveMQConnect
ion.java:1243)
... 6 more
and we basically need to reconnect the clients to be able to run things
again.
Googling a bit and reading the documentation on the activemq site showed
that there is a way to turn the "inactivity policy" off, but the posts
that google found and the actual docs are sketchy and conflicting a bit.
Some posts say that all that's needed is passing the
wireFormat.maxInactivityDuration=0 pair on the connect string that the
client is using (tcp://x.x.x.x:61616?
wireFormat.maxInactivityDuration=0). The documentation however hints
that this parameter needs to match the broker's configuration as well.
More specifically this page
http://activemq.apache.org/configuring-wire-formats.html says "When
using the maxInactivityDuration option, the setting must match on both
sides of the connection. The default value the maxInactivityDuration
option on the broker side is 30 seconds so each consumer must have the
same setting so that the option actually takes effect. If the settings
do not match, the option will have no effect". I looked here -
http://activemq.apache.org/configuring-transports.html - in the "Server
Side Options" section and could not spot any transport connector option
that specifies the server side maxInactivityDuration setting.
Long story short, the questions I have are:
1) By default what is the duration that causes the
InactivityIOException-s? The documentation suggests 30 seconds, but I do
not experience it in that short of a frame.
2) How can I turn inactivity timeouts off? Is there a way to find out
(log, etc) whether the turn-inactivity-monitoring-off configuration is
in effect (short of leaving the environment inactive for a long period
of time and trying activity)?
Help/feedback will be much appreciated.
Thanks,
-nik
