Open yamii opened 8 years ago
I use wascally.startSubscription( <queueName> )
and it's not working fine instead of calling Responder.handle
. Is this the right way to do it?
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 https://github.com/LeanKit-Labs/wascally/issues/115 and it looks like https://github.com/LeanKit-Labs/wascally/issues/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
@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.
@derickbailey using startSubscription( queue_name )
to all queues except my replyQueue( since it was configured to subscribe:false ) did work fine in my end.
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
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
?
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 👍
I'm using
request-respond
pattern in where at some point Ireset
rabbitmq server connection. When I make arequest
I do receive arespond
but I receive ittwice
. In rabbitmq management UI, I can see myrequester's response queue
having1 unack
message.I did listen to wascally
aquired
connection when connection is back call againResponder.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?