You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by veechand <ve...@cisco.com> on 2008/06/16 09:50:20 UTC
Impact due to wireformat.maxInactivityDuration=0
In our application we are using ActiveMQ. Currently we facing
"javax.jms.IllegalStateException: The Session is closed", this exception
occurs immediately after "Channel was inactive for too long". On searching
on this we found an option for disabling the inactive timer, namely
wireformat.maxInactivityDuration=0. We have added this during intialization
of TopicConnectionFactory. Since this issue is not reproduced consistently,
we like to know on the following
1. Is there any impact due disabling timeout.
2. Will there be any increase in recourses like socket, file handle,
threads, memory
3. Any consistent way to reproduce the issue.
Background:
Our application is a web based application. Uses ActiveMQ to pass events
between JVMs. There are events which are passed so infrequently and those
that are passed very frequently.
--
View this message in context: http://www.nabble.com/Impact-due-to-wireformat.maxInactivityDuration%3D0-tp17859607p17859607.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Impact due to wireformat.maxInactivityDuration=0
Posted by Sharon Barker <sh...@intalgent.com>.
Hi,
Our application had a similar issue bridging between brokers on
different networks. We were able to reproduce the problem in a testing
environment by fiddling with iptables to completely sever connectivity
on one broker machine. In our case that made sense because in the wild
the devices are physically separate and network issues (latency, lost
packets, somebody's ill advised firewall rule, etc) happen all the
time. In our tests we found that "shutdown" was either normal or
sudden traffic stop (iptables change.)
One additional note which may (or may not) apply to your situation...
we found that we had to set both brokers to have non-zero values for
wireformat.maxInactivityDuration for the bridge to come back up at
all. Once that was done, all was well in both 4.1.2 and 5.1.0 in our
app.
Hope that helps a little.
Sharon
On Jun 16, 2008, at 6:16 AM, veechand wrote:
>
> Thanks Marco.
> By shutdown do you mean normal shutdown or client/broker getting
> abruptly
> down. If getting abruptly down what could be reason for the same,
> this will
> help in reproducing the same?
> We are using 4.1, yet to migrate to 5.1. Since this is critical time
> in our
> project we are not migrating now and going with this fix.
> Moreover do you mean this issue is
> http://issues.apache.org/activemq/browse/AMQ-1146, if not can you
> kindly
> point me to the same.
>
>
> Marco Buss wrote:
>>
>> Hi,
>>
>> we ave the same problem here. Setting
>> wireformat.maxInactivityDuration=0
>> was not a good idea because the shutdown of client or broker (i cant
>> remeber) is not recognised. So try if your client get notice of
>> broker
>> shutdown and vice versa.
>>
>> Which version of activeMQ did you use? With 5.1 the problem is fixed.
>>
>>
>> veechand wrote:
>>>
>>> In our application we are using ActiveMQ. Currently we facing
>>> "javax.jms.IllegalStateException: The Session is closed", this
>>> exception
>>> occurs immediately after "Channel was inactive for too long". On
>>> searching on this we found an option for disabling the inactive
>>> timer,
>>> namely wireformat.maxInactivityDuration=0. We have added this during
>>> intialization of TopicConnectionFactory. Since this issue is not
>>> reproduced consistently, we like to know on the following
>>> 1. Is there any impact due disabling timeout.
>>> 2. Will there be any increase in recourses like socket, file
>>> handle,
>>> threads, memory
>>> 3. Any consistent way to reproduce the issue.
>>>
>>> Background:
>>> Our application is a web based application. Uses ActiveMQ to pass
>>> events between JVMs. There are events which are passed so
>>> infrequently
>>> and those that are passed very frequently.
>>>
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Impact-due-to-wireformat.maxInactivityDuration%3D0-tp17859607p17861634.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
Re: Impact due to wireformat.maxInactivityDuration=0
Posted by veechand <ve...@cisco.com>.
Thanks Marco.
By shutdown do you mean normal shutdown or client/broker getting abruptly
down. If getting abruptly down what could be reason for the same, this will
help in reproducing the same?
We are using 4.1, yet to migrate to 5.1. Since this is critical time in our
project we are not migrating now and going with this fix.
Moreover do you mean this issue is
http://issues.apache.org/activemq/browse/AMQ-1146, if not can you kindly
point me to the same.
Marco Buss wrote:
>
> Hi,
>
> we ave the same problem here. Setting wireformat.maxInactivityDuration=0
> was not a good idea because the shutdown of client or broker (i cant
> remeber) is not recognised. So try if your client get notice of broker
> shutdown and vice versa.
>
> Which version of activeMQ did you use? With 5.1 the problem is fixed.
>
>
> veechand wrote:
>>
>> In our application we are using ActiveMQ. Currently we facing
>> "javax.jms.IllegalStateException: The Session is closed", this exception
>> occurs immediately after "Channel was inactive for too long". On
>> searching on this we found an option for disabling the inactive timer,
>> namely wireformat.maxInactivityDuration=0. We have added this during
>> intialization of TopicConnectionFactory. Since this issue is not
>> reproduced consistently, we like to know on the following
>> 1. Is there any impact due disabling timeout.
>> 2. Will there be any increase in recourses like socket, file handle,
>> threads, memory
>> 3. Any consistent way to reproduce the issue.
>>
>> Background:
>> Our application is a web based application. Uses ActiveMQ to pass
>> events between JVMs. There are events which are passed so infrequently
>> and those that are passed very frequently.
>>
>
>
--
View this message in context: http://www.nabble.com/Impact-due-to-wireformat.maxInactivityDuration%3D0-tp17859607p17861634.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Impact due to wireformat.maxInactivityDuration=0
Posted by Marco Buss <ma...@gmx.de>.
Hi,
we ave the same problem here. Setting wireformat.maxInactivityDuration=0 was
not a good idea because the shutdown of client or broker (i cant remeber) is
not recognised. So try if your client get notice of broker shutdown and vice
versa.
Which version of activeMQ did you use? With 5.1 the problem is fixed.
veechand wrote:
>
> In our application we are using ActiveMQ. Currently we facing
> "javax.jms.IllegalStateException: The Session is closed", this exception
> occurs immediately after "Channel was inactive for too long". On searching
> on this we found an option for disabling the inactive timer, namely
> wireformat.maxInactivityDuration=0. We have added this during
> intialization of TopicConnectionFactory. Since this issue is not
> reproduced consistently, we like to know on the following
> 1. Is there any impact due disabling timeout.
> 2. Will there be any increase in recourses like socket, file handle,
> threads, memory
> 3. Any consistent way to reproduce the issue.
>
> Background:
> Our application is a web based application. Uses ActiveMQ to pass
> events between JVMs. There are events which are passed so infrequently and
> those that are passed very frequently.
>
--
View this message in context: http://www.nabble.com/Impact-due-to-wireformat.maxInactivityDuration%3D0-tp17859607p17861336.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.