Menu
The tutorials on RabbitMq's site are pretty straight forward, but I noticed that in the Rpc example, the developers choose to use the thread-blocking call consumer.Queue.Dequeue() instead of using the EventingBasicConsumer and the event handling model used elsewhere.
Looking through the current documentation it is stated that
As of version 3.5.0 application callback handlers can invoke blocking operations (such as
IModel.QueueDeclareorIModel.BasicCancel).IBasicConsumercallbacks are invoked concurrently.
Where as the old documentation (v. 1.5.0) states that it is not supported
Application callback handlers must not invoke blocking AMQP operations (such as
IModel.QueueDeclareorIModel.BasicCancel). If they do, the channel will deadlock. [...] For this reason,QueueingBasicConsumeris the safest way of subscribing to a queue.
Could it be that the RPC example hasn't been updated? Or am I missing something? I would very much appreciate to be pointed to some documentation about this.
981
This pattern is commonly known as Remote Procedure Call or RPC. In this tutorial we're going to use RabbitMQ to build an RPC system: a client and a scalable RPC server. As we don't have any time-consuming tasks that are worth distributing, we're going to create a dummy RPC service that returns Fibonacci numbers.
In automatic acknowledgement mode, a message is considered to be successfully delivered immediately after it is sent. This mode trades off higher throughput (as long as the consumers can keep up) for reduced safety of delivery and consumer processing. This mode is often referred to as "fire-and-forget".
You're right, there is no need to use QueueingBasicConsumer.
There is an issue in RabbitMQ tutorials repo about this.
I've sent a pull request and it was merged, hope the documentation will be updated soon.
182
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
