Hi Mathew..<br><br><div class="gmail_quote">On Tue, Nov 10, 2009 at 8:46 PM, Matthew Sackman <span dir="ltr">&lt;<a href="mailto:matthew@lshift.net">matthew@lshift.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Arun,<br>
<div class="im"><br>
On Mon, Nov 09, 2009 at 07:58:36AM +0530, Arun Suresh wrote:<br>
&gt; &gt; Can you elaborate on this issue a bit? Is this redirection coming back<br>
&gt; &gt; from the server?<br>
&gt; &gt;<br>
&gt; Yes.. I guess its a redirection request coming from the server..<br>
&gt; basicaly.. the response to my &#39;connection.open&#39; request is a<br>
&gt; &#39;conncetion.redirect&#39; which on recipt, the client throws an exception and<br>
&gt; exits..<br>
&gt; ive gotten around this issue by setting &#39;insist = true&#39; in the request<br>
&gt; record...<br>
&gt; Maybe ill look at the Java client and see whats done there ?<br>
<br>
</div>The redirection stuff has gone from AMQP 0.9.1 so there&#39;s not a huge<br>
need to worry about it if you&#39;re just experimenting for the time being.<br>
The idea is that in a cluster, a node can request that you change the<br>
connection to a different node, for load balancing reasons. The Java and<br>
.Net clients both detect these errors and attempt to obey the<br>
redirection requests.<br>
<div class="im"><br>
&gt; &gt; Well client@m1 died. This means its subscriptions to Q were lost - there<br>
&gt; &gt; is no concept of persisting subscriptions, so when rabbit@m1 comes back<br>
&gt; &gt; up, the Q will have no consumers at all. If you restart client@m2 then<br>
&gt; &gt; yes, it&#39;ll recreate its subscription to Q, and thus receive all the msgs<br>
&gt; &gt; sent to that Q. If you also restart client@m1 then that too will<br>
&gt; &gt; recreate its subscription to Q and share the msgs with client@m2 as<br>
&gt; &gt; before.<br>
&gt; &gt;<br>
&gt;<br>
&gt; Confirms what ive been thinking... But Is there any way for clients to be<br>
&gt; notified of dead subscriptions ? That would be helpful, else i would have to<br>
&gt; keep polling something to get that information..<br>
<br>
</div>Well, you could simply check to see if the socket is still open. If the<br>
broker goes down then your network socket from the client will also go<br>
down.<br></blockquote><div><br></div><div>:) thing is.. I have clients connected to the RabbitMQ instance that DIDNT go down.. but have subscriptions to Queues persisted on the instance that did..</div><div>These clients wont know if queue is gone or not...�</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888"><br>
Matthew<br>
</font></blockquote></div>-Arun