qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruno Matos <bruno.ma...@paradigmaxis.pt>
Subject Re: [c++]: Progressing AMQP 1.0 support for 0.22 release
Date Thu, 23 May 2013 13:03:49 GMT
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-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message