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:[email protected] > > > -- 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:[email protected]
