On 11/28/2013 06:29 PM, Gordon Sim wrote:
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...
I have a binding manager service in A to handle bindings requests (the
part that I omitted in previous email). My first approach will be having
this manager waiting for the binding event on 'federated' B queue, to
send the answer to the binding request made by the client, this will
force the client to wait before send the request.
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.
I've tried that approach, as you may remember, but I was not able to
fulfill all the requirements for the Windows client, so I'm making a
middle step.
Thank you,
Regards.
--
Bruno Matos
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
