<html>
<head>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
So, I seem to have encountered a limitation with Federation. This
is with regards to how bindings of exchanges/queues are propagated
asynchronously, thus leading to the possibility of a race condition.<br>
<br>
If you take the example outlined in Tutorial Six (
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a href="http://www.rabbitmq.com/tutorials/tutorial-six-python.html">http://www.rabbitmq.com/tutorials/tutorial-six-python.html</a>),
and modify the code so that exchanges are used, you can get RPC
requests and responses to traverse federated links. In this
example, the rpc_client creates a temporary callback queue and
attaches the address of that queue to the message as a reply_to
property. Once the rpc_server receives the message and calculates
the Fibonacci number, it sends the response back via a new message
to the reply_to address...<br>
<br>
Ok. This is all simple basic stuff to this point.<br>
<br>
The problem lies in when the rpc_client creates it's temporary
callback queue. There is a race condition in which the rpc_client
may move on by then sending the fib(n) message, the rpc_server
receives + calculates the Fibonacci number, and then sends a
response to the rpc_client's callback queue specified in
props.reply_to -- all before the Federation plugin has propagated
the binding of the callback queue to the exchange and other
federated exchanges. Thus, the response message gets lost/dropped.<br>
<br>
Has anybody else experienced an issue like this? Does anybody have
suggestions as to how to properly provide RPC functionality across
federated exchanges?<br>
<br>
Thanks!<br>
<br>
<pre class="moz-signature" cols="72">--
Josh West
One.com - <a class="moz-txt-link-freetext" href="http://www.one.com">http://www.one.com</a></pre>
</body>
</html>