You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Mohit Anchlia <mo...@gmail.com> on 2013/01/30 20:05:40 UTC
Channel was inactive for too long error
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.
Re: Channel was inactive for too long error
Posted by Andreas Calvo Gómez <an...@scytl.com>.
Sorry, I meant
5.1.2 on the other computer, run ant producer -Dtopic=true -Dmax=999999
On 31/01/13 20:17, Andreas Calvo Gómez wrote:
> 5.1.2 on the other computer, run ant consumer -Dtopic=true -Dmax=999999
--
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.
Re: Channel was inactive for too long error
Posted by 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.
Re: Channel was inactive for too long error
Posted by Mohit Anchlia <mo...@gmail.com>.
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.
>
>
Re: Channel was inactive for too long error
Posted by Andreas Calvo Gómez <an...@scytl.com>.
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
>>>> <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>
>>>>>
>>>>> 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.
Re: Channel was inactive for too long error
Posted by Mohit Anchlia <mo...@gmail.com>.
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
>>> <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>
>>>>
>>>> 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.
>
>
Re: Channel was inactive for too long error
Posted by Andreas Calvo Gómez <an...@scytl.com>.
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).
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 <mo...@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
>>>
>>> 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
>>>>> twitter: @christianposta
>>>>>
>>>
>>>
>>> --
>>> *Christian Posta*
>>> 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.
Re: Channel was inactive for too long error
Posted by Mohit Anchlia <mo...@gmail.com>.
Thanks! I'll try that. If I apply maxInactivityDuration just on server then
would client recognize that? I wanted to disable it to see if it helps.
On Thu, Jan 31, 2013 at 12:31 PM, Christian Posta <christian.posta@gmail.com
> wrote:
> try escaping the '&'
>
>
> On Thu, Jan 31, 2013 at 11:48 AM, Mohit Anchlia <mohitanchlia@gmail.com
> >wrote:
>
> > I tried to set Inactivity duration like this but activemq didn't start.
> It
> > says it needs ";" at the end. Am I doing something wrong?
> >
> >
> > Caused by: org.xml.sax.SAXParseException: The reference to entity
> > "wireFormat.maxInactivityDuration" must end with the ';' delimiter.
> >
> >
> > <transportConnector name="openwire" uri="nio://
> >
> 0.0.0.0:61616?transport.closeAsync=false&wireFormat.maxInactivityDuration=0<http://0.0.0.0:61616/?transport.closeAsync=false&wireFormat.maxInactivityDuration=0>
> > "
> > enableStatusMonitor="true"/>
> >
> >
> > On Wed, Jan 30, 2013 at 4:11 PM, Christian Posta
> > <ch...@gmail.com>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
> > > > >
> > > > > 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
> > > > > > > twitter: @christianposta
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > *Christian Posta*
> > > > > http://www.christianposta.com/blog
> > > > > twitter: @christianposta
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > *Christian Posta*
> > > http://www.christianposta.com/blog
> > > twitter: @christianposta
> > >
> >
>
>
>
> --
> *Christian Posta*
> http://www.christianposta.com/blog
> twitter: @christianposta
>
Re: Channel was inactive for too long error
Posted by Christian Posta <ch...@gmail.com>.
try escaping the '&'
On Thu, Jan 31, 2013 at 11:48 AM, Mohit Anchlia <mo...@gmail.com>wrote:
> I tried to set Inactivity duration like this but activemq didn't start. It
> says it needs ";" at the end. Am I doing something wrong?
>
>
> Caused by: org.xml.sax.SAXParseException: The reference to entity
> "wireFormat.maxInactivityDuration" must end with the ';' delimiter.
>
>
> <transportConnector name="openwire" uri="nio://
> 0.0.0.0:61616?transport.closeAsync=false&wireFormat.maxInactivityDuration=0
> "
> enableStatusMonitor="true"/>
>
>
> On Wed, Jan 30, 2013 at 4:11 PM, Christian Posta
> <ch...@gmail.com>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
> > > >
> > > > 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
> > > > > > twitter: @christianposta
> > > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > *Christian Posta*
> > > > http://www.christianposta.com/blog
> > > > twitter: @christianposta
> > > >
> > >
> >
> >
> >
> > --
> > *Christian Posta*
> > http://www.christianposta.com/blog
> > twitter: @christianposta
> >
>
--
*Christian Posta*
http://www.christianposta.com/blog
twitter: @christianposta
Re: Channel was inactive for too long error
Posted by Mohit Anchlia <mo...@gmail.com>.
I tried to set Inactivity duration like this but activemq didn't start. It
says it needs ";" at the end. Am I doing something wrong?
Caused by: org.xml.sax.SAXParseException: The reference to entity
"wireFormat.maxInactivityDuration" must end with the ';' delimiter.
<transportConnector name="openwire" uri="nio://
0.0.0.0:61616?transport.closeAsync=false&wireFormat.maxInactivityDuration=0"
enableStatusMonitor="true"/>
On Wed, Jan 30, 2013 at 4:11 PM, Christian Posta
<ch...@gmail.com>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
> > >
> > > 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
> > > > > twitter: @christianposta
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > *Christian Posta*
> > > http://www.christianposta.com/blog
> > > twitter: @christianposta
> > >
> >
>
>
>
> --
> *Christian Posta*
> http://www.christianposta.com/blog
> twitter: @christianposta
>
Re: Channel was inactive for too long error
Posted by Christian Posta <ch...@gmail.com>.
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 <mo...@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
> >
> > 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
> > > > twitter: @christianposta
> > > >
> > >
> >
> >
> >
> > --
> > *Christian Posta*
> > http://www.christianposta.com/blog
> > twitter: @christianposta
> >
>
--
*Christian Posta*
http://www.christianposta.com/blog
twitter: @christianposta
Re: Channel was inactive for too long error
Posted by Mohit Anchlia <mo...@gmail.com>.
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
>
> 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
> > > twitter: @christianposta
> > >
> >
>
>
>
> --
> *Christian Posta*
> http://www.christianposta.com/blog
> twitter: @christianposta
>
Re: Channel was inactive for too long error
Posted by Christian Posta <ch...@gmail.com>.
There were some issues around NIO and stomp/mqtt that Tim resolved here:
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 <mo...@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
> > twitter: @christianposta
> >
>
--
*Christian Posta*
http://www.christianposta.com/blog
twitter: @christianposta
Re: Channel was inactive for too long error
Posted by Mohit Anchlia <mo...@gmail.com>.
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
> twitter: @christianposta
>
Re: Channel was inactive for too long error
Posted by Christian Posta <ch...@gmail.com>.
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 <mo...@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
twitter: @christianposta