activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Calvo Gómez <andreas.ca...@scytl.com>
Subject Re: Channel was inactive for too long error
Date Thu, 31 Jan 2013 19:17:02 GMT
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>
>> ).
>> 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
>>>> <christian.posta@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>
>>>>>
>>>>> 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>
>>>>>>> twitter: @christianposta
>>>>>>>
>>>>>>>
>>>>> --
>>>>> *Christian Posta*
>>>>> 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.


Mime
View raw message