[rabbitmq-discuss] Weird Issue when cluster member restarts

[Arun Suresh]

Hi Mathew..

On Tue, Nov 10, 2009 at 8:46 PM, Matthew Sackman <matthew at lshift.net> wrote:

> Hi Arun,
>
> On Mon, Nov 09, 2009 at 07:58:36AM +0530, Arun Suresh wrote:
> > > Can you elaborate on this issue a bit? Is this redirection coming back
> > > from the server?
> > >
> > Yes.. I guess its a redirection request coming from the server..
> > basicaly.. the response to my 'connection.open' request is a
> > 'conncetion.redirect' which on recipt, the client throws an exception and
> > exits..
> > ive gotten around this issue by setting 'insist = true' in the request
> > record...
> > Maybe ill look at the Java client and see whats done there ?
>
> The redirection stuff has gone from AMQP 0.9.1 so there's not a huge
> need to worry about it if you're just experimenting for the time being.
> The idea is that in a cluster, a node can request that you change the
> connection to a different node, for load balancing reasons. The Java and
> .Net clients both detect these errors and attempt to obey the
> redirection requests.
>
> > > Well client at m1 died. This means its subscriptions to Q were lost -
> there
> > > is no concept of persisting subscriptions, so when rabbit at m1 comes
> back
> > > up, the Q will have no consumers at all. If you restart client at m2 then
> > > yes, it'll recreate its subscription to Q, and thus receive all the
> msgs
> > > sent to that Q. If you also restart client at m1 then that too will
> > > recreate its subscription to Q and share the msgs with client at m2 as
> > > before.
> > >
> >
> > Confirms what ive been thinking... But Is there any way for clients to be
> > notified of dead subscriptions ? That would be helpful, else i would have
> to
> > keep polling something to get that information..
>
> Well, you could simply check to see if the socket is still open. If the
> broker goes down then your network socket from the client will also go
> down.
>

:) 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..
These clients wont know if queue is gone or not...

>
> Matthew
>
-Arun
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20091110/b78c284f/attachment.htm