Hi,<br><br>Yep, I decided on the last option. ;)<br><br>Thanks for the help<br><br>Roaan<br><br><div class="gmail_quote">On 6 May 2010 16:24, Emile Joubert <span dir="ltr"><<a href="mailto:emile@rabbitmq.com">emile@rabbitmq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><br>
Hi Roaan,<br>
<br>
If you are concerned about receiving messages asynchronously between binding and unbinding the queue then you could cancel the subscription first. Be aware that messages may still end up in the queue, even if they are not delivered. It would of course be preferable to avoid the entire sequence (cancel subscription, bind, unbind) if there was no binding in the first place.<br>
<br>
Another approach is to allow the exception to occur and recover from it by re-establishing the connection.<br>
<br>
<br>
-Emile<br>
<br>
<br>
<br>
<br>
Roaan Vos wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi,<br>
<br><div class="im">
On second thought, I don't think that will work.<br>
<br>
If I first do the binding, the client will likely receive data he didn't intend before being able to remove the binding.<br>
<br>
Since consuming messages off of the queue is happening asynchronously, while the bind/unbind happens on a different connection I think the above is quite possible.<br>
<br>
Thanks<br>
<br>
Roaan<br>
<br>
<br></div><div class="im">
On 6 May 2010 13:20, Emile Joubert <<a href="mailto:emile@rabbitmq.com" target="_blank">emile@rabbitmq.com</a> <mailto:<a href="mailto:emile@rabbitmq.com" target="_blank">emile@rabbitmq.com</a>>> wrote:<br>
<br>
<br>
Hi Roaan,<br>
<br>
The broker is required to raise a connection exception if an unbind<br>
fails, so you are describing expected behaviour.<br>
<br>
Duplicate bindings will be ignored, so you can prevent the exception<br>
by performing a (possibly duplicate) binding immediately prior to<br>
unbind.<br>
<br>
The client is expected to keep track of bindings under normal<br>
circumstances though. I assume this is impossible in your case - can<br>
you explain why?<br>
<br>
-Emile<br>
<br>
Roaan Vos wrote:<br>
<br>
Hi,<br>
<br>
I currently allow clients to “bind” and “unbind” to various<br>
topics as needed using the .net client.<br>
<br>
However, when the client “unbinds” without first having done a<br>
bind, RabbitMQ throws an exception and the connection seems to<br>
disappear.<br>
<br>
Is there a way for it to keep the connection (or not throw an<br>
exception)?<br>
<br>
Thanks<br>
<br>
Roaan<br>
<br>
<br>
------------------------------------------------------------------------<br>
<br>
_______________________________________________<br>
rabbitmq-discuss mailing list<br>
<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a><br></div>
<mailto:<a href="mailto:rabbitmq-discuss@lists.rabbitmq.com" target="_blank">rabbitmq-discuss@lists.rabbitmq.com</a>><div class="im"><br>
<a href="http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss" target="_blank">http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss</a><br>
</div></blockquote>
</blockquote></div><br>