Hello Mathew..<br><br>Thank you for your reply..<br><br><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
> Also, It would be really awesome if somebody would explain to me what is the<br>
> recommended approach to a situation when a node goes down.<br>
<br>
</div>Depends massively on your situation. Clustering in Rabbit is meant to<br>
facilitate scalability, not high availability. If you could provide some<br>
further details of your scenario, we'd be better able to advise.<br>
<br>
Matthew<br><br></blockquote><div><br>Ok.. Here is a very simplistic description of our setup.. <br><br>Assume we have 2 rabbit nodes.. R1 and R2.<br>and 2 Clinets C1 and C2 (running the same code-base). C1 on startup creates a connection to R1, creates and subscribes to a queue 'Q'. C2 on startup creates connection to R2 and subscribes to the same Q. So now we have Q created on R1 but 2 consumers subscribing to it. <br>
<br>Q is bound to a direct exchange X. The idea is that a producer might publish an event on X.. which can be handled by either C1 or C2.<br><br>Up until now (since we were using Rabbit 1.7.0), If say R1 goes down, C1 is notified (since it is connected to R1) so C1 reconnects to R2 and recreates the Q on R2.. it also notifies C2.. so C2 can re-connect to R2 and re-subscribe to the new queue (also named Q)..<br>
Thus... Thus any event sent on X will still be routed to C1 or C2. (Only caveat is... when R1 comes back, all messages that were in the Old queue is appended to the New queue.... since we arnt really particular about the ordering.. that should be fine..)<br>
<br>How do think we should tackle this situation now ?<br><br>Thanx in Advance<br>-Arun<br><br>� � <br></div></div>