What I described is the behavior of the current broker. Have you
considered updating?
Jonathan
H. Charles Tang wrote:
./qpidd --version
qpidd (qpidc) version 0.2
Pls let me know if you need anything else,
Thanks
--- On Thu, 10/15/09, Ted Ross <[email protected]> wrote:
From: Ted Ross <[email protected]>
Subject: Re: looping of qpid routes
To: [email protected]
Cc: [email protected]
Date: Thursday, October 15, 2009, 2:18 PM
Which version of the software are you
running?
-Ted
H. Charles Tang wrote:
Thanks folks for your help.
I think you're telling me that what we did for setting
up two routes on a single link as follows should not cause a
msg loop:
qpid-route route add host1:5000 host2:5000 amq.topic
topic.foo
qpid-route route add host2:5000 host1:5000 amq.topic
topic.foo
However what we have observed is different. The msg
consumer couldn't
keep up with the looping msg and eventually crashed.
Charles
--- On Thu, 10/15/09, Carl Trieloff <[email protected]>
wrote:
From: Carl Trieloff <[email protected]>
Subject: Re: looping of qpid routes
To: [email protected]
Date: Thursday, October 15, 2009, 9:35 AM
Also, a header is used on the message to prevent
loop
detection.
Carl.
Jonathan Robie wrote:
Bidirectional links are fine, and
automatically detect
loops. Tree, star, or line topologies are fine
too, and
bidirectional links between any pair of brokers
are fine. A
ring topology is also possible, if only
unidirectional links
are used.
Here's the rule:
For any pair of nodes A,B in a federated
network,
there should be only one path from A to B. If
there is more
than one path, message loops can cause duplicate
message
transmission and flood the federated network. The
topologies
discussed above do not have message loops. A ring
topology
with bidirectional links is one example of a
topology that
does cause this problem, because a given broker
can receive
the same message from two different brokers. Mesh
topologies
can also cause this problem.
Every message transfer takes time. For better
performance, you should minimize the number of
brokers
between the message origin and final destination.
In most
cases, tree or star topologies do this best.
Hope this helps!
Jonathan
H. Charles Tang wrote:
Have created 2 static routes as follows
between
our 2 qpid daemons housed on two linux hosts
respectively:
qpid-route route add host1:5000
host2:5000
amq.topic topic.foo
qpid-route route add host2:5000
host1:5000
amq.topic topic.foo
Does this create an infinite loop for a
message
between 2 qpids? Our experiment confirmed the
looping
scenario.
Then how does one create a bi-directional
route?
or how do we interpret the following in the qpid
documentation:
"Routes are unidirectional. A single
route
provides for the flow of messages in one direction
across a
link. If bidirectional connectivity is required
(and it
almost always is), then a pair of routes must be
created,
one for each direction of message flow."
Finally does qpid (daemon) do loop
detection/handling?
Thanks.
Charles
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging
Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
