On Qui, 2013-05-23 at 13:20 +0100, Gordon Sim wrote: > On 05/23/2013 11:08 AM, Bruno Matos wrote: > > My motivation to use the domain feature has to do with sending messages > > from a service connected to source broker directly to a queue in > > destination broker, if you remember my first questions about it. But I > > don't know how can achieve that. > > So, just to ensure I understand correctly, you have a service that > subscribes to a request queue on broker A and a client that wants to use > that service, connected to broker B. The client sends a message that > should be transmitted across from B to A. The message contains a reply > to that refers to a queue on B and responses should go there. >
Yes, that's it. > To achieve this with 0-10 based federation, you need to have the > response queue bound to some explicit exchange (not simply the default > exchange) and use that exchange in the reply-to address (along with a > unique binding/routing key if the exchange is shared by other > responses). E.g. create a 'responses' exchange (as a direct exchange) > and then use 'response/#' as the address for the response receiver, > passing the generated unique address in as the reply-to. > > Part of the goals of the 1.0 federation equivalent was to make this more > seamless/transparent and less dependent on pre 1.0 exchange types. You > can configure each broker to know about the other (i.e. setup a domain), > and then access queues on another broker through > <queue-name>@<broker-name>. So for a my-responses queue on broker B, > broker A could access that directly as my-responses@BrokerB (assuming a > domain named BrokerB has been configured with the details of how to > connect). It should work now, with the domains configured with qpid-ctrl and a sender created with my-queue@my-domain ? In the test I run it complains that there is no such queue. > > The next step is to make the qualification of the queue name by domain > more transparent. For temp queues in 1.0, the broker assigns the name > and passes this back to the client and the broker can be configured to > add the necessary qualification transparently. I've just committed a fix > to trunk that makes that work in such a way as to allow the > client/server example shipped with the c++ messaging client to be able > to be run against a pair of brokers without changing the examples > themselves. That isn't possible yet on 0.20 (or 0.22) though I'm afraid, > but hopefully it gives some idea of the motivation and direction. > > And of course this is not limited to reply queues. You can use this to > access nodes of any type in any other process that accepts 1.0 > connections. E.g. if you have systems using ActiveMQ or SwiftMQ and need > access to a particular piece of functionality or a particular > source/sink for messages on those from clients connected to qpidd you > can do that quite simply also (or even access a standalone proton based > service). > Thank you. -- Bruno Matos --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
