How do rabbus handle rebuilding back the topology upon reconnection?

[yamii]

I'm using request-respond pattern in where at some point I reset rabbitmq server connection.
When I make a request I do receive a respond but I receive it twice.
In rabbitmq management UI, I can see my requester's response queue having 1 unack message.

I did listen to wascally aquired connection when connection is back call again Responder.handle for queues to start subscription. I'm not pretty sure I'm doing it correctly.

Is there a better/right way to do it?

[yamii]

I use wascally.startSubscription( <queueName> ) and it's not working fine instead of calling Responder.handle. Is this the right way to do it?

[mxriverlynn]

Generally speaking, wascally will re-connect all of the subscriptions when the server drops and comes back online.

There's some discussion on this in the wascally issues list at LeanKit-Labs/wascally#115 and it looks like LeanKit-Labs/wascally#119 will address the issue that rabbus has.

Internally, rabbus uses subscribe: false in the settings, and then calls startSubscription once things are configured, and according to ticket 119 in wascally, these subscriptions won't restart automatically right now.

i'll have to do some testing to see how this should best be handled with rabbus, until the wascally fix is in place (which is technically done... but on a fork of the project).

FWIW, my general strategy of losing a connection to crash the app and restart everything from the ground up. i do this for just about all exceptions. i find it easier to not deal with reconnect and continuing... just tear it all down, and restart the app so it can rebuild everything from the start.

i'll dig into this, though, and see what i can find

[yamii]

@derickbailey thanks! ATM also we were doing the same thing you were doing ( crashing the app ) but we'll be having issues if we restart the application when rabbitmq connection cuts off.

[yamii]

@derickbailey using startSubscription( queue_name ) to all queues except my replyQueue( since it was configured to subscribe:false ) did work fine in my end.

[mxriverlynn]

glad to hear it's working @yamii

i'm still wondering, though, if the configuration has an exclusive / auto delete queue, would it get rebuilt on reconnect? this seems like a scenario that should be handled.

still haven't had a chance to dig into this, but i've been working on #21 which will hopefully make some of this easier to get right

[yamii]

for autoDelete:true I would say it use subscribe:true then it will rebuild as long as there are still consumers. I think we still have the same issue with subscribe:false in this case.

what scenario autoDelete: true will be best use of aside from using it in replyQueue?

[mxriverlynn]

the primary use case for autoDelete: true is subscribers in a true pub-sub scenario, where the subscriber does not need any history - only what happens when it is connected.

i'm having a hard time coming up with good examples... but the idea is a consumer would create a queue for itself, configure a binding key for an exchange, and read messages as they come in. for whatever reason, that consumer does not need a permanent queue, collecting messages for later consumption. when the consumer closes, it's queue goes away so the server won't overload a queue that will no longer be used

Hi @derickbailey, have you had any further thoughts on this recently?

I'm having trouble re-establishing my consumers with Rabbus and Wascally/Rabbot using the examples/watchmecode tutorials. I can resort to exiting and restarting my application which does the trick, but I don't really like that behaviour.

I want to be able to set up my consumers/handlers on a reconnect, but having difficulties in doing so.

Been looking at the wascally/rabbot libraries, and issues on all three repositories but had no luck. I was tying in to the connected method and trying to establish my connections there, but wasn't sure how to attach the handlers.

Any advice would be greatly appreciated 👍