Re: Channel was inactive for too long error

[Andreas Calvo Gómez <an...@scytl.com>]

Take a look at http://activemq.apache.org/configuring-wire-formats.html 
to see an example.
On 31/01/13 20:46, Mohit Anchlia wrote:
> Thanks! but I am not even able to add maxInactivityDuration to the uri. Is
> there a workaround for that?
>
> On Thu, Jan 31, 2013 at 11:17 AM, Andreas Calvo Gómez <
> andreas.calvo@scytl.com> wrote:
>
>> No, it's still an issue really easy to reproduce.
>> I'm trying to get a Use Case well defined, but it's hard to simulate a
>> stalled network using multicast when one can't interfere directly in the
>> connection between the brokers (and the error still relies on handling the
>> TCP connection status).
>>
>> Steps to reproduce:
>> 0. get two machines with java and ant installed
>> 1. download latest release
>> 2. uncompress compressed file
>> 3.1 on one computer copy {AMQ-ROOT}/conf/activemq-**dynamic-network-broker1.xml
>> as conf/activemq.xml
>> 3.2 on the other computer copy {AMQ-ROOT}/conf/activemq-**dynamic-network-broker2.xml
>> as conf/activemq.xml
>> 4. start the broker ({AMQ-ROOT}/bin/activemq console to see the log)
>> 5.1 enter {AMQ-ROOT}/example directory
>> 5.1.1 on one computer, run ant consumer -Ddurable=true -Dtopic=true
>> -Dmax=999999
>> 5.1.2 on the other computer, run ant consumer -Dtopic=true -Dmax=999999
>> 6. once the message start to flow, unplug a network cable
>> 7. wait at least Inactivity Timeout time (default value is 30000ms)
>> 8. once the InactivityMonitor error appears (channel was inactive for too
>> long), plug the network cable and you'll see a lot of errors
>> (InvalidClientIDException: Broker: BROKER - Client: CLIENT already
>> connected on URI) and pending message will not flow to reach the desired
>> number.
>>
>>
>> On 31/01/13 20:01, Mohit Anchlia wrote:
>>
>>> If this is closed I am assuming there is a workaround.
>>>
>>> On Thu, Jan 31, 2013 at 10:52 AM, Andreas Calvo Gómez <
>>> andreas.calvo@scytl.com> wrote:
>>>
>>>   Christian,
>>>> I do have seen this error a lot, and in fact it's critical.
>>>> We discussed this with Gary but the bug got closed without a confirmation
>>>> of a fix ( https://issues.apache.org/****jira/browse/AMQ-3353<https://issues.apache.org/**jira/browse/AMQ-3353>
>>>> <https://**issues.apache.org/jira/browse/**AMQ-3353<https://issues.apache.org/jira/browse/AMQ-3353>>
>>>>
>>>>
>>>> ).
>>>> In fact, I'm writing a test case now because using the Multicast
>>>> Transport
>>>> Protocol happens the same.
>>>>
>>>> On 31/01/13 01:11, Christian Posta wrote:
>>>>
>>>>   Still not sure if there is a problem. How long in between writes would
>>>>> you
>>>>> say elapses?
>>>>> Can you put a sample together showing the problem?
>>>>>
>>>>>
>>>>> On Wed, Jan 30, 2013 at 5:07 PM, Mohit Anchlia <mohitanchlia@gmail.com
>>>>>
>>>>>> wrote:
>>>>>>
>>>>> We are using mule and activemq 5.7.0. Is there a workaround for this
>>>>>
>>>>>> problem?
>>>>>>
>>>>>> On Wed, Jan 30, 2013 at 2:59 PM, Christian Posta
>>>>>> <ch...@gmail.com>****wrote:
>>>>>>
>>>>>>
>>>>>> There were some issues around NIO and stomp/mqtt that Tim resolved
>>>>>> here:
>>>>>>
>>>>>>> https://issues.apache.org/****jira/browse/AMQ-4106<https://issues.apache.org/**jira/browse/AMQ-4106>
>>>>>>> <https://**issues.apache.org/jira/browse/**AMQ-4106<https://issues.apache.org/jira/browse/AMQ-4106>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> But you'd have to tell more about your transportConnectors to say
>>>>>>> whether
>>>>>>> it's related.
>>>>>>> Otherwise, if you can reproduce what you're seeing and attach to a
>>>>>>> JIRA
>>>>>>> (preferably in a test case) I'll take care of it for you.
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Jan 30, 2013 at 1:07 PM, Mohit Anchlia <
>>>>>>> mohitanchlia@gmail.com
>>>>>>>
>>>>>>> wrote:
>>>>>>>> We are always writing and this happens when we are actively writing
>>>>>>>> successfully and then all of a sudden mq detects this to be a bad
>>>>>>>> connection.
>>>>>>>>
>>>>>>>> On Wed, Jan 30, 2013 at 11:59 AM, Christian Posta <
>>>>>>>> christian.posta@gmail.com
>>>>>>>>
>>>>>>>> wrote:
>>>>>>>>> There's usually a good reason for it. Means a transport didn't
>>>>>>>>>
>>>>>>>>> receive
>>>>>>> any
>>>>>>>
>>>>>>>> data in a period of time... Are you seeing it in the broker logs?
>>>>>>>>>
>>>>>>>>> On Wed, Jan 30, 2013 at 12:05 PM, Mohit Anchlia <
>>>>>>>>>
>>>>>>>>> mohitanchlia@gmail.com
>>>>>>>>    wrote:
>>>>>>>>
>>>>>>>>> We often see
>>>>>>>>>> Channel was inactive for too long
>>>>>>>>>>
>>>>>>>>>> Our MQ and app is in same network and is reliable. I have tested
>>>>>>>>>>
>>>>>>>>>> the
>>>>>>>>    network and it looks like there is a bug in this check. I don't see
>>>>>>>> any
>>>>>>>> bug
>>>>>>>>
>>>>>>>>>   files, is anyone aware of this?
>>>>>>>>>> It also appears others either disable it or increase the inactivity
>>>>>>>>>>
>>>>>>>>>> period
>>>>>>>>> as workaround.
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>> *Christian Posta*
>>>>>>>>> http://www.christianposta.com/****blog<http://www.christianposta.com/**blog>
>>>>>>>>> <http://www.**christianposta.com/blog<http://www.christianposta.com/blog>
>>>>>>>>> twitter: @christianposta
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>> *Christian Posta*
>>>>>>> http://www.christianposta.com/****blog<http://www.christianposta.com/**blog>
>>>>>>> <http://www.**christianposta.com/blog<http://www.christianposta.com/blog>
>>>>>>> twitter: @christianposta
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>   --
>>>> Andreas Calvo Gómez
>>>> Systems Engineer
>>>> Scytl Secure Electronic Voting
>>>> Plaça Gal·la Placidia, 1-3, 1st floor · 08006 Barcelona
>>>> Phone: + 34 934 230 324
>>>> Fax:   + 34 933 251 028
>>>> http://www.scytl.com
>>>>
>>>> NOTICE: The information in this e-mail and in any of its attachments is
>>>> confidential and intended solely for the attention and use of the named
>>>> addressee(s). If you are not the intended recipient, any disclosure,
>>>> copying,
>>>> distribution or retaining of this message or any part of it, without the
>>>> prior
>>>> written consent of Scytl Secure Electronic Voting, SA is prohibited and
>>>> may be
>>>> unlawful. If you have received this in error, please contact the sender
>>>> and
>>>> delete the material from any computer.
>>>>
>>>>
>>>>
>> --
>> Andreas Calvo Gómez
>> Systems Engineer
>> Scytl Secure Electronic Voting
>> Plaça Gal·la Placidia, 1-3, 1st floor · 08006 Barcelona
>> Phone: + 34 934 230 324
>> Fax:   + 34 933 251 028
>> http://www.scytl.com
>>
>> NOTICE: The information in this e-mail and in any of its attachments is
>> confidential and intended solely for the attention and use of the named
>> addressee(s). If you are not the intended recipient, any disclosure,
>> copying,
>> distribution or retaining of this message or any part of it, without the
>> prior
>> written consent of Scytl Secure Electronic Voting, SA is prohibited and
>> may be
>> unlawful. If you have received this in error, please contact the sender
>> and
>> delete the material from any computer.
>>
>>

-- 
Andreas Calvo Gómez
Systems Engineer
Scytl Secure Electronic Voting
Plaça Gal·la Placidia, 1-3, 1st floor · 08006 Barcelona
Phone: + 34 934 230 324
Fax:   + 34 933 251 028
http://www.scytl.com

NOTICE: The information in this e-mail and in any of its attachments is
confidential and intended solely for the attention and use of the named
addressee(s). If you are not the intended recipient, any disclosure,
copying,
distribution or retaining of this message or any part of it, without the
prior
written consent of Scytl Secure Electronic Voting, SA is prohibited and
may be
unlawful. If you have received this in error, please contact the sender
and
delete the material from any computer.