You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by ffrenchm <ff...@gmail.com> on 2009/03/09 16:37:06 UTC
Question about QPID broker federation
Hello,
I would like to know if it's possible to configure QPID to route messages
from a broker A to a broker C through a broker B. In fact I aim to achieve
this kind of topology :
client X (network 1) send Message to Broker C via Broker A -> broker A
(network 1) send message to broker C via broker B -> broker B (network 1 and
network 2) send message to broker C-> broker C (network 2) <- client Y
(network 2) receive the message from client X
The broker B in fact is a kind of hub broker which links network 1 and
network 2. After reading the broker federation documentation I do not find
the way to achieve this kind of topology. Any idea ?
Thanks
--
View this message in context: http://n2.nabble.com/Question-about-QPID-broker-federation-tp2449651p2449651.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Question about QPID broker federation
Posted by ffrenchm <ff...@gmail.com>.
Thanks for your answer Ted ! In fact I created the two queues becauses I was
inspired by another queuer way of making federation to configure my QPID
federation that's why I did this error with QPID... Now it's very clear and
I must say I like the QPID/AMQP power !
Ted Ross wrote:
>
> ffrenchm wrote:
>> I'm trying to play with the QPID broker federation. And now I've another
>> question :)
>>
>> Let's begin by explaining my configuration. I've two connected brokers :
>>
>> on broker A :
>> ------------------
>>
>> the queues :
>>
>> Queue Name Attributes
>> ===========================================================================
>> bridge_queue_1_2785d679-8177-4303-a936-95b40e3412bf auto-del excl
>> bridge_queue_2_2785d679-8177-4303-a936-95b40e3412bf auto-del excl
>> bridge_queue_3_2785d679-8177-4303-a936-95b40e3412bf auto-del excl
>> fed.direct.q1
>> fed.direct.q2
>> reply-dekatonshir.21103.1 auto-del excl
>> topic-dekatonshir.21103.1 auto-del excl
>>
>> the exchanges :
>>
>> Type Exchange Name Attributes
>> ==================================================
>> direct
>> topic qpid.management
>> direct amq.direct --durable
>> topic amq.topic --durable
>> fanout amq.fanout --durable
>> headers amq.match --durable
>> topic fed.topic
>> fanout fed.fanout
>> direct fed.direct
>>
>> the queue fed.direct.q1 is binded to exchanges fed.direct with routing
>> key
>> q1
>> the queue fed.direct.q1 is binded to exchanges fed.direct with routing
>> key
>> q2
>>
>> the route map :
>>
>> Finding Linked Brokers:
>> localhost:5672... Ok
>> localhost:5673... Ok
>>
>> Dynamic Routes:
>>
>> Exchange fed.topic:
>> localhost:5673 <=> localhost:5672
>>
>> Exchange fed.fanout:
>> localhost:5673 <=> localhost:5672
>>
>> Exchange fed.direct:
>> localhost:5673 <=> localhost:5672
>>
>> Static Routes:
>> none found
>>
>> On broker B :
>> -------------------
>>
>> the queues :
>>
>> Queue Name Attributes
>> ===========================================================================
>> bridge_queue_1_6f009106-2ffc-4f13-bbb8-1521556ba314 auto-del excl
>> bridge_queue_2_6f009106-2ffc-4f13-bbb8-1521556ba314 auto-del excl
>> bridge_queue_3_6f009106-2ffc-4f13-bbb8-1521556ba314 auto-del excl
>> fed.direct.q1
>> fed.direct.q2
>> reply-dekatonshir.21135.1 auto-del excl
>> topic-dekatonshir.21135.1 auto-del excl
>>
>> the exchanges :
>>
>> Type Exchange Name Attributes
>> ==================================================
>> direct
>> topic qpid.management
>> direct amq.direct --durable
>> topic amq.topic --durable
>> fanout amq.fanout --durable
>> headers amq.match --durable
>> topic fed.topic
>> fanout fed.fanout
>> direct fed.direct
>>
>> the route map :
>>
>> Finding Linked Brokers:
>> localhost:5673... Ok
>> localhost:5672... Ok
>>
>> Dynamic Routes:
>>
>> Exchange fed.topic:
>> localhost:5672 <=> localhost:5673
>>
>> Exchange fed.fanout:
>> localhost:5672 <=> localhost:5673
>>
>> Exchange fed.direct:
>> localhost:5672 <=> localhost:5673
>>
>> Static Routes:
>> none found
>>
>> the queue fed.direct.q1 is binded to exchanges fed.direct with routing
>> key
>> q1
>> the queue fed.direct.q1 is binded to exchanges fed.direct with routing
>> key
>> q2
>>
>> So the aim of my test is to check the behaviour of QPID with a dubious
>> test:
>>
>> I'm sending a message to the exchange fed.direct with the routing key q1
>> on
>> broker A. With my routing configuration that's mean my messages will be
>> routed to Broker B on the exchange fed.direct with the routing_key q1
>> (and
>> so in the queue fed.direct.q1) and it appends :
>>
>> ./direct_consumer.py localhost 5672 fed.direct.q1
>> message 0
>> message 1
>> message 2
>> message 3
>> message 4
>> message 5
>> message 6
>> message 7
>> message 8
>> message 9
>> That's all, folks!
>>
>> But when trying to check if the messages has been consumed in the broker
>> A
>> I'm a little disapointed because it's not the case :
>>
>> ./direct_consumer.py localhost 5673 fed.direct.q1
>> message 0
>> message 1
>> message 2
>> message 3
>> message 4
>> message 5
>> message 6
>> message 7
>> message 8
>> message 9
>> That's all, folks!
>>
>> Is it because message sended on the queue fed.direct.q1 on broker B are
>> re
>> sended on broker A ? Did I miss something ?
>>
>> Thanks
>>
>>
> I think there is a misunderstanding of how broker federation works. In
> your case, you created queues on both brokers. These queues are both
> bound to the fed.direct exchange and therefore both receive copies of
> messages that match the binding key. These queues (fed.direct.q1 on
> broker A and fed.direct.q1 on broker B) are separate, independent queues
> and have no relationship to each other. The behavior you are seeing is
> correct.
>
> I don't know what your application is, but might clustering be more
> appropriate for what you are doing? Clustering makes multiple brokers
> behave as one logical broker.
>
> Federation, on the other hand, provides for routing between separate,
> distinct brokers. Dynamic routing in federation creates the illusion of
> a single, distributed exchange. It does not have the same effect on
> queues.
>
> -Ted
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
>
>
--
View this message in context: http://n2.nabble.com/Question-about-QPID-broker-federation-tp2449651p2450785.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Question about QPID broker federation
Posted by Ted Ross <tr...@redhat.com>.
ffrenchm wrote:
> I'm trying to play with the QPID broker federation. And now I've another
> question :)
>
> Let's begin by explaining my configuration. I've two connected brokers :
>
> on broker A :
> ------------------
>
> the queues :
>
> Queue Name Attributes
> ===========================================================================
> bridge_queue_1_2785d679-8177-4303-a936-95b40e3412bf auto-del excl
> bridge_queue_2_2785d679-8177-4303-a936-95b40e3412bf auto-del excl
> bridge_queue_3_2785d679-8177-4303-a936-95b40e3412bf auto-del excl
> fed.direct.q1
> fed.direct.q2
> reply-dekatonshir.21103.1 auto-del excl
> topic-dekatonshir.21103.1 auto-del excl
>
> the exchanges :
>
> Type Exchange Name Attributes
> ==================================================
> direct
> topic qpid.management
> direct amq.direct --durable
> topic amq.topic --durable
> fanout amq.fanout --durable
> headers amq.match --durable
> topic fed.topic
> fanout fed.fanout
> direct fed.direct
>
> the queue fed.direct.q1 is binded to exchanges fed.direct with routing key
> q1
> the queue fed.direct.q1 is binded to exchanges fed.direct with routing key
> q2
>
> the route map :
>
> Finding Linked Brokers:
> localhost:5672... Ok
> localhost:5673... Ok
>
> Dynamic Routes:
>
> Exchange fed.topic:
> localhost:5673 <=> localhost:5672
>
> Exchange fed.fanout:
> localhost:5673 <=> localhost:5672
>
> Exchange fed.direct:
> localhost:5673 <=> localhost:5672
>
> Static Routes:
> none found
>
> On broker B :
> -------------------
>
> the queues :
>
> Queue Name Attributes
> ===========================================================================
> bridge_queue_1_6f009106-2ffc-4f13-bbb8-1521556ba314 auto-del excl
> bridge_queue_2_6f009106-2ffc-4f13-bbb8-1521556ba314 auto-del excl
> bridge_queue_3_6f009106-2ffc-4f13-bbb8-1521556ba314 auto-del excl
> fed.direct.q1
> fed.direct.q2
> reply-dekatonshir.21135.1 auto-del excl
> topic-dekatonshir.21135.1 auto-del excl
>
> the exchanges :
>
> Type Exchange Name Attributes
> ==================================================
> direct
> topic qpid.management
> direct amq.direct --durable
> topic amq.topic --durable
> fanout amq.fanout --durable
> headers amq.match --durable
> topic fed.topic
> fanout fed.fanout
> direct fed.direct
>
> the route map :
>
> Finding Linked Brokers:
> localhost:5673... Ok
> localhost:5672... Ok
>
> Dynamic Routes:
>
> Exchange fed.topic:
> localhost:5672 <=> localhost:5673
>
> Exchange fed.fanout:
> localhost:5672 <=> localhost:5673
>
> Exchange fed.direct:
> localhost:5672 <=> localhost:5673
>
> Static Routes:
> none found
>
> the queue fed.direct.q1 is binded to exchanges fed.direct with routing key
> q1
> the queue fed.direct.q1 is binded to exchanges fed.direct with routing key
> q2
>
> So the aim of my test is to check the behaviour of QPID with a dubious test:
>
> I'm sending a message to the exchange fed.direct with the routing key q1 on
> broker A. With my routing configuration that's mean my messages will be
> routed to Broker B on the exchange fed.direct with the routing_key q1 (and
> so in the queue fed.direct.q1) and it appends :
>
> ./direct_consumer.py localhost 5672 fed.direct.q1
> message 0
> message 1
> message 2
> message 3
> message 4
> message 5
> message 6
> message 7
> message 8
> message 9
> That's all, folks!
>
> But when trying to check if the messages has been consumed in the broker A
> I'm a little disapointed because it's not the case :
>
> ./direct_consumer.py localhost 5673 fed.direct.q1
> message 0
> message 1
> message 2
> message 3
> message 4
> message 5
> message 6
> message 7
> message 8
> message 9
> That's all, folks!
>
> Is it because message sended on the queue fed.direct.q1 on broker B are re
> sended on broker A ? Did I miss something ?
>
> Thanks
>
>
I think there is a misunderstanding of how broker federation works. In
your case, you created queues on both brokers. These queues are both
bound to the fed.direct exchange and therefore both receive copies of
messages that match the binding key. These queues (fed.direct.q1 on
broker A and fed.direct.q1 on broker B) are separate, independent queues
and have no relationship to each other. The behavior you are seeing is
correct.
I don't know what your application is, but might clustering be more
appropriate for what you are doing? Clustering makes multiple brokers
behave as one logical broker.
Federation, on the other hand, provides for routing between separate,
distinct brokers. Dynamic routing in federation creates the illusion of
a single, distributed exchange. It does not have the same effect on queues.
-Ted
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Question about QPID broker federation
Posted by ffrenchm <ff...@gmail.com>.
I'm must say I did the same test with a static uni directional route and I've
the same problem. The messages are never consumed on the source broker and I
do not know how to force the consumption of messages in the source broker. I
do not understand the reason of this behaviour : is it not dangerous to keep
message duplicates in the brokers network ?
ffrenchm wrote:
>
> I'm trying to play with the QPID broker federation. And now I've another
> question :)
>
> Let's begin by explaining my configuration. I've two connected brokers :
>
> on broker A :
> ------------------
>
> the queues :
>
> Queue Name Attributes
> ===========================================================================
> bridge_queue_1_2785d679-8177-4303-a936-95b40e3412bf auto-del excl
> bridge_queue_2_2785d679-8177-4303-a936-95b40e3412bf auto-del excl
> bridge_queue_3_2785d679-8177-4303-a936-95b40e3412bf auto-del excl
> fed.direct.q1
> fed.direct.q2
> reply-dekatonshir.21103.1 auto-del excl
> topic-dekatonshir.21103.1 auto-del excl
>
> the exchanges :
>
> Type Exchange Name Attributes
> ==================================================
> direct
> topic qpid.management
> direct amq.direct --durable
> topic amq.topic --durable
> fanout amq.fanout --durable
> headers amq.match --durable
> topic fed.topic
> fanout fed.fanout
> direct fed.direct
>
> the queue fed.direct.q1 is binded to exchanges fed.direct with routing key
> q1
> the queue fed.direct.q1 is binded to exchanges fed.direct with routing key
> q2
>
> the route map :
>
> Finding Linked Brokers:
> localhost:5672... Ok
> localhost:5673... Ok
>
> Dynamic Routes:
>
> Exchange fed.topic:
> localhost:5673 <=> localhost:5672
>
> Exchange fed.fanout:
> localhost:5673 <=> localhost:5672
>
> Exchange fed.direct:
> localhost:5673 <=> localhost:5672
>
> Static Routes:
> none found
>
> On broker B :
> -------------------
>
> the queues :
>
> Queue Name Attributes
> ===========================================================================
> bridge_queue_1_6f009106-2ffc-4f13-bbb8-1521556ba314 auto-del excl
> bridge_queue_2_6f009106-2ffc-4f13-bbb8-1521556ba314 auto-del excl
> bridge_queue_3_6f009106-2ffc-4f13-bbb8-1521556ba314 auto-del excl
> fed.direct.q1
> fed.direct.q2
> reply-dekatonshir.21135.1 auto-del excl
> topic-dekatonshir.21135.1 auto-del excl
>
> the exchanges :
>
> Type Exchange Name Attributes
> ==================================================
> direct
> topic qpid.management
> direct amq.direct --durable
> topic amq.topic --durable
> fanout amq.fanout --durable
> headers amq.match --durable
> topic fed.topic
> fanout fed.fanout
> direct fed.direct
>
> the route map :
>
> Finding Linked Brokers:
> localhost:5673... Ok
> localhost:5672... Ok
>
> Dynamic Routes:
>
> Exchange fed.topic:
> localhost:5672 <=> localhost:5673
>
> Exchange fed.fanout:
> localhost:5672 <=> localhost:5673
>
> Exchange fed.direct:
> localhost:5672 <=> localhost:5673
>
> Static Routes:
> none found
>
> the queue fed.direct.q1 is binded to exchanges fed.direct with routing key
> q1
> the queue fed.direct.q1 is binded to exchanges fed.direct with routing key
> q2
>
> So the aim of my test is to check the behaviour of QPID with a dubious
> test:
>
> I'm sending a message to the exchange fed.direct with the routing key q1
> on broker A. With my routing configuration that's mean my messages will be
> routed to Broker B on the exchange fed.direct with the routing_key q1 (and
> so in the queue fed.direct.q1) and it appends :
>
> ./direct_consumer.py localhost 5672 fed.direct.q1
> message 0
> message 1
> message 2
> message 3
> message 4
> message 5
> message 6
> message 7
> message 8
> message 9
> That's all, folks!
>
> But when trying to check if the messages has been consumed in the broker A
> I'm a little disapointed because it's not the case :
>
> ./direct_consumer.py localhost 5673 fed.direct.q1
> message 0
> message 1
> message 2
> message 3
> message 4
> message 5
> message 6
> message 7
> message 8
> message 9
> That's all, folks!
>
> Is it because message sended on the queue fed.direct.q1 on broker B are re
> sended on broker A ? Did I miss something ?
>
> Thanks
>
>
--
View this message in context: http://n2.nabble.com/Question-about-QPID-broker-federation-tp2449651p2450576.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Question about QPID broker federation
Posted by ffrenchm <ff...@gmail.com>.
I'm trying to play with the QPID broker federation. And now I've another
question :)
Let's begin by explaining my configuration. I've two connected brokers :
on broker A :
------------------
the queues :
Queue Name Attributes
===========================================================================
bridge_queue_1_2785d679-8177-4303-a936-95b40e3412bf auto-del excl
bridge_queue_2_2785d679-8177-4303-a936-95b40e3412bf auto-del excl
bridge_queue_3_2785d679-8177-4303-a936-95b40e3412bf auto-del excl
fed.direct.q1
fed.direct.q2
reply-dekatonshir.21103.1 auto-del excl
topic-dekatonshir.21103.1 auto-del excl
the exchanges :
Type Exchange Name Attributes
==================================================
direct
topic qpid.management
direct amq.direct --durable
topic amq.topic --durable
fanout amq.fanout --durable
headers amq.match --durable
topic fed.topic
fanout fed.fanout
direct fed.direct
the queue fed.direct.q1 is binded to exchanges fed.direct with routing key
q1
the queue fed.direct.q1 is binded to exchanges fed.direct with routing key
q2
the route map :
Finding Linked Brokers:
localhost:5672... Ok
localhost:5673... Ok
Dynamic Routes:
Exchange fed.topic:
localhost:5673 <=> localhost:5672
Exchange fed.fanout:
localhost:5673 <=> localhost:5672
Exchange fed.direct:
localhost:5673 <=> localhost:5672
Static Routes:
none found
On broker B :
-------------------
the queues :
Queue Name Attributes
===========================================================================
bridge_queue_1_6f009106-2ffc-4f13-bbb8-1521556ba314 auto-del excl
bridge_queue_2_6f009106-2ffc-4f13-bbb8-1521556ba314 auto-del excl
bridge_queue_3_6f009106-2ffc-4f13-bbb8-1521556ba314 auto-del excl
fed.direct.q1
fed.direct.q2
reply-dekatonshir.21135.1 auto-del excl
topic-dekatonshir.21135.1 auto-del excl
the exchanges :
Type Exchange Name Attributes
==================================================
direct
topic qpid.management
direct amq.direct --durable
topic amq.topic --durable
fanout amq.fanout --durable
headers amq.match --durable
topic fed.topic
fanout fed.fanout
direct fed.direct
the route map :
Finding Linked Brokers:
localhost:5673... Ok
localhost:5672... Ok
Dynamic Routes:
Exchange fed.topic:
localhost:5672 <=> localhost:5673
Exchange fed.fanout:
localhost:5672 <=> localhost:5673
Exchange fed.direct:
localhost:5672 <=> localhost:5673
Static Routes:
none found
the queue fed.direct.q1 is binded to exchanges fed.direct with routing key
q1
the queue fed.direct.q1 is binded to exchanges fed.direct with routing key
q2
So the aim of my test is to check the behaviour of QPID with a dubious test:
I'm sending a message to the exchange fed.direct with the routing key q1 on
broker A. With my routing configuration that's mean my messages will be
routed to Broker B on the exchange fed.direct with the routing_key q1 (and
so in the queue fed.direct.q1) and it appends :
./direct_consumer.py localhost 5672 fed.direct.q1
message 0
message 1
message 2
message 3
message 4
message 5
message 6
message 7
message 8
message 9
That's all, folks!
But when trying to check if the messages has been consumed in the broker A
I'm a little disapointed because it's not the case :
./direct_consumer.py localhost 5673 fed.direct.q1
message 0
message 1
message 2
message 3
message 4
message 5
message 6
message 7
message 8
message 9
That's all, folks!
Is it because message sended on the queue fed.direct.q1 on broker B are re
sended on broker A ? Did I miss something ?
Thanks
--
View this message in context: http://n2.nabble.com/Question-about-QPID-broker-federation-tp2449651p2450340.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Question about QPID broker federation
Posted by ffrenchm <ff...@gmail.com>.
Carl Trieloff wrote:
>
> ffrenchm wrote:
>> Hello,
>>
>> I would like to know if it's possible to configure QPID to route messages
>> from a broker A to a broker C through a broker B. In fact I aim to
>> achieve
>> this kind of topology :
>>
>> client X (network 1) send Message to Broker C via Broker A -> broker A
>> (network 1) send message to broker C via broker B -> broker B (network 1
>> and
>> network 2) send message to broker C-> broker C (network 2) <- client Y
>> (network 2) receive the message from client X
>>
>> The broker B in fact is a kind of hub broker which links network 1 and
>> network 2. After reading the broker federation documentation I do not
>> find
>> the way to achieve this kind of topology. Any idea ?
>>
>> Thanks
>>
>>
>>
> Yes, this is possible, see tthe examples at the bottom of this page
> http://qpid.apache.org/using-broker-federation.html
>
> Carl.
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
>
>
>
uhm you right, I didn't read the entire paper :) Thanks !
--
View this message in context: http://n2.nabble.com/Question-about-QPID-broker-federation-tp2449651p2449974.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org
Re: Question about QPID broker federation
Posted by Carl Trieloff <cc...@redhat.com>.
ffrenchm wrote:
> Hello,
>
> I would like to know if it's possible to configure QPID to route messages
> from a broker A to a broker C through a broker B. In fact I aim to achieve
> this kind of topology :
>
> client X (network 1) send Message to Broker C via Broker A -> broker A
> (network 1) send message to broker C via broker B -> broker B (network 1 and
> network 2) send message to broker C-> broker C (network 2) <- client Y
> (network 2) receive the message from client X
>
> The broker B in fact is a kind of hub broker which links network 1 and
> network 2. After reading the broker federation documentation I do not find
> the way to achieve this kind of topology. Any idea ?
>
> Thanks
>
>
>
Yes, this is possible, see tthe examples at the bottom of this page
http://qpid.apache.org/using-broker-federation.html
Carl.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:users-subscribe@qpid.apache.org