On 11/28/2013 05:40 PM, Bruno Matos wrote:
Hello,
I'm using dynamic routes between two federated Brokers and I'm having
some problems.
Here is the scenario: I have one client connected to one Broker (A),
which sends a request to a service witch is connected to another Broker
(B). There is a dynamic route from Broker B to A, on exchange amq.direct.
The client creates a queue, sends a binding request for the queue with a
given address to Broker A via qmf (it's more complicated that this, but
I think this is a good representation of the process), when the answer
to that binding request arrives, it sends a request to the service
connected to Broker B with a ReplyTo set for the address that it
initially asked the binding. Most of the time the response message
arrives without problems, but once in a while, the response message is
lost.
Is it possible that the service at Broker B answers before the binding
to the 'federation' queue is made?
The propagation of the binding is asynchronous, so it is not guaranteed
that B has received the bind request from A at the point your client
receives confirmation of the bind from A.
You don't mention how the federation is set up in order to get the
request from A to B. Assuming it is being pulled by B, it will be going
over a different connection than that used to send the bind request from
A to B.
So it is possible that B gets the message before it gets the bind
request and I suppose even possible in theory that it delivers the
message to the service and receives a response back from the service
before the bind is acted on.
I'm not sure how best to handle that. The client could I suppose try to
send itself a message via broker B - e.g. have a fanout exchange on A
with a static route to the dynamically federated exchange on B, send a
message to that with the appropriate routing key - and then wait for
that message to arrive before sending the service request. A bit over
complicated however...
Reply-to in general is not well handled by federation at all. I made a
stab at improving this a little for the 1.0 implementation and Ted has
focused on making reply-to work much transparently with the Dispatch
Router.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
