Closed dentarg closed 7 years ago
👍
I think this could be useful when testing in projects depending upon twingly-amqp
.
Hmm, I don't really remember the problem anymore. Maybe we will have our minds refreshed once we start working with Wally + twingly-amqp.
I think I know what this is about now. I believe this is the problem: https://github.com/twingly/twingly-amqp/blob/d802bdd8ee991af92247b44c0e411247e4079ea7/lib/twingly/amqp/subscription.rb#L44 it makes it hard to use in tests.
Relevant docs, http://rubybunny.info/articles/queues.html#handling_messages_with_a_block
The subscribe method will not block the calling thread by default. If you want to block the thread, pass
:block => true
toBunny::Queue#subscribe
. In Bunny 0.9.0 and later, network activity and dispatch of delivered messages to consumers happens in separate threads that Bunny maintains internally, so it does not have to block the thread that callsBunny::Queue#subscribe
. However, it may be convenient to do so in long-running consumer applications.
For Twingly::AMQP::Subscription
E.g.
#on_each_message
, similar to the#on_exception
we have