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.ca...@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.ca...@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 <mohitanch...@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.po...@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 <
>>>>>> mohitanch...@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.po...@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 <
>>>>>>>>
>>>>>>>> mohitanch...@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.
>
>
