You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Nik Kolev <nk...@healthmarketscience.com> on 2011/03/29 17:03:25 UTC
how do i stop session Inactivity monitoring/enforcing?
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
RE: how do i stop session Inactivity monitoring/enforcing?
Posted by Nik Kolev <nk...@healthmarketscience.com>.
Thanks for the prompt reply.
I'd like to make sure I understand my options:
Option 1:
Just change activemq.xml broker config (please check how I am specifying the parameter):
<transportConnectors>
<transportConnector name="openwire" uri="tcp://0.0.0.0:61616?wireFormat.maxInactivityDuration=0"/>
</transportConnectors>
...and regardless what the clients say (nothing or something specific) the 0 (no inactivity monitoring) wins?
Option 2:
Change the activemq broker config:
<transportConnectors>
<transportConnector name="openwire" uri="tcp://0.0.0.0:61616?transport.useInactivityMonitor=false"/>
</transportConnectors>
And the client connect URL:
tcp://host:61616?useInactivityMonitor=false
...but if the client does not specify 'useInactivityMonitor=false' and uses something between [1,30] or nothing (the default 30) there *will be* inactivity monitoring for this particular client connection?
-nik
-----Original Message-----
From: Gary Tully [mailto:gary.tully@gmail.com]
Sent: Tuesday, March 29, 2011 11:47 AM
To: users@activemq.apache.org
Subject: Re: how do i stop session Inactivity monitoring/enforcing?
the value used is the min of the client and broker values. When
disabling it, using 0, the 0 always wins. When increasing it past the
default 30, both ends need to agree.
There is an option to disable the Inactivity monitor filter
altogether, such that there
is no negotiation. On the server, use:
tcp://localhost:XXX?transport.useInactivityMonitor=false
options prefixed with transport are applied to new transport
connections rather than to the bound socket.
And configure the client via:
tcp://host:xxx?useInactivityMonitor=false
On 29 March 2011 16:03, Nik Kolev <nk...@healthmarketscience.com> wrote:
> 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
>
>
>
--
http://blog.garytully.com
http://fusesource.com
Re: how do i stop session Inactivity monitoring/enforcing?
Posted by Gary Tully <ga...@gmail.com>.
the value used is the min of the client and broker values. When
disabling it, using 0, the 0 always wins. When increasing it past the
default 30, both ends need to agree.
There is an option to disable the Inactivity monitor filter
altogether, such that there
is no negotiation. On the server, use:
tcp://localhost:XXX?transport.useInactivityMonitor=false
options prefixed with transport are applied to new transport
connections rather than to the bound socket.
And configure the client via:
tcp://host:xxx?useInactivityMonitor=false
On 29 March 2011 16:03, Nik Kolev <nk...@healthmarketscience.com> wrote:
> 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
>
>
>
--
http://blog.garytully.com
http://fusesource.com