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.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.
--
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.
