Blocked consumer in separate thread

36 views
Skip to first unread message

Dimitri Pekarovsky

unread,
Jun 30, 2019, 11:06:05 AM6/30/19
to Ruby RabbitMQ libraries
Hi, all and Michael.

Will the the consumer started with block: true in separated thread block all others bunny consumers?
I drawing the schema now for a service with load like ~5 new threads (=requests) in second and time to live from 10 to 600 seconds for one thread.
Is this strategy ok for such service?

As I get so far for now:
  1. One connection for program (microservice)
  2. One channel and queue for the Thread
  3. Queue will bind to topic (There are others microservices, that listens for the same routing keys as commands)
  4. The channel must be closed (and the temporary queue will be deleted) when this Thread will close.
So it looks like there will be about 600 (pessimistic) simultaneous threads with every of them holding one consumer blocking that thread, and the same count of channels, queues, binds to one topic.
Are there potentially places for memory leak? Like many binds/unbinds etc. Will they block each other?

Michael Klishin

unread,
Jun 30, 2019, 11:56:56 AM6/30/19
to Ruby RabbitMQ libraries
block: true is never OK. It was added to use in tutorials to keep the main thread alive in case the app
was only consuming, a decision I greatly regret now.

What it does is it blocks the *caller* (the calling thread) until the channel’s consumer work pool is active.
It has no effect on any other consumers or the consumer dispatch mechanism, which is still entirely asynchronous.

To reiterate, consider Bunny::Queue#subscribe(block: true) to be NOT appropriate in ANY circumstances. I tried to eradicate it from all of the tutorials and docs recently. Let me know if it’s still present somewhere (in master, rabbitmq/rabbitmq-website, rabbitmq/rabbitmq-tutorials and so on).

Dimitri Pekarovsky:

Michael Klishin

unread,
Jun 30, 2019, 11:57:28 AM6/30/19
to Ruby RabbitMQ libraries
block: true is never OK. It was added to use in tutorials to keep the main thread alive in case the app
was only consuming, a decision I greatly regret now.

What it does is it blocks the *caller* (the calling thread) until the channel’s consumer work pool is active.
It has no effect on any other consumers or the consumer dispatch mechanism, which is still entirely asynchronous.

To reiterate, consider Bunny::Queue#subscribe(block: true) to be NOT appropriate in ANY circumstances. I tried to eradicate it from all of the tutorials and docs recently. Let me know if it’s still present somewhere (in master, rabbitmq/rabbitmq-website, rabbitmq/rabbitmq-tutorials and so on).

> --
> Bunny: http://rubybunny.info
> March Hare: http://rubymarchhare.info
>
> IRC: #rabbitmq on irc.freenode.net
>
> Post to the group: ruby...@googlegroups.com | unsubscribe: ruby-amqp+...@googlegroups.com
> ---
> You received this message because you are subscribed to the Google Groups "Ruby RabbitMQ libraries" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ruby-amqp+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/ruby-amqp/91f55ef7-81e4-45f0-b8e6-6cb204cb6a8a%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Dimitri Pekarovsky

unread,
Jun 30, 2019, 12:02:43 PM6/30/19
to Ruby RabbitMQ libraries
Ok, I got. Thank you. The rest of my estimates are ok?

воскресенье, 30 июня 2019 г., 18:56:56 UTC+3 пользователь Michael Klishin написал:
Reply all
Reply to author
Forward
0 new messages