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: [email protected] For additional commands, e-mail: [email protected]
