qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Broker Federation - replying to queue
Date Mon, 04 Feb 2013 18:10:13 GMT
On 02/04/2013 04:25 PM, Bruno Matos wrote:
> Anyway, I was hoping that would be a more transparent way to do this.
> Replicating all the queues seams overkill.
> One way could be change the default exchange to something else, but that
> means change the behavior of many components in the system.

That was going to be my suggestion(!). In its simplest form, if you are 
creating temporary response queues on demand in the clients, would be to 
change from using e.g. '#' to 'amq.direct/#' as the address for these 
clients. That does likely require a change to all the clients though.

In a variation of this, if the senders used reply-to addresses of the 
form 'amq.fanout/<queue-name>', where <queue-name> is the name of their 
reply queue then the server connected to B2 will send the replies to 
amq.fanout, with the routing key set to <queue-name>.

You could then create a bridge from amq.fanout on B2 to the default 
exchange on B1. Unfortunately you can't do that through qpid-route as it 
forces the name of the exchange in a route to be the same, but that is a 
limitation of the options to that tool rather than the actual mechanism. 
You can use qpid-tool or a custom script instead.

Now all the replies would get to their intended queue without requiring 
any extra bindings or whatever on B1.

The disadvantage of course is that this scheme now *requires* 
federation. If you decommissioned B2 and connected the server directly 
to B1, then the modified reply-to address would no longer be valid.

And of course it still requires updating all the clients, so its likely 
not any improvement.

> Any other suggestion(s) would be really appreciated.

To get around the need to alter clients, you could instead try a 
modification to the server program such that it handled the reply-to 
differently for requests that came via federation (e.g. by pre-pending 
'amq.fanout/' to the address supplied by the client in that case.

One way of differentiating between federated requests and others would 
be to check the x-qpid.trace property on the message. (Another would be 
to have such messages come via a different queue and update the server 
to listen on both).

I'm not sure if this is any better... the bottom line is that there is 
no nice transparent solution to reply-to in federation as yet.

To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message