[rabbitmq-discuss] Using BlockingConnection in Pika

Gavin M. Roy gmr at myyearbook.com
Tue Jul 5 22:19:20 BST 2011

On Tue, Jul 5, 2011 at 5:04 PM, Joshua Braegger <rckclmbr at gmail.com> wrote:
> Thanks, Jason.
> I bring this up because of this comment
> -- http://tonyg.github.com/pika/connecting.html#adapters-blocking-connection-blockingconnection
> "Warning BlockingConnection is provided for legacy and learning purposes
> only and it is not recommended that you use it for a production
> application."
> The latest git documentation also still has this warning
> (https://github.com/pika/pika/blob/master/pika/adapters/base_connection.py)
> "adapters.blocking_connection.BlockingConnection: Enables blocking,
>   synchronous operation on top of library for simple uses. This is not
>   recommended and is included for legacy reasons only."
> So my question is, why isn't this recommended for production use?

In essence, you can but the main issue is it's a synchronous "hack" on
top of an asynchronous stack using an asynchronous protocol. I am
working on a revamped method of handling the blocking but it's taking
a bit longer than I'd like.

The best way to think of the BlockingConnection adapter is as a layer
on top of the existing client that implements blocking behaviors.
Every other adapter plugs into the driver.

At the time I wrote that it was deprecated, I wasn't planning on
keeping it long term. My impression of it and how to handle it has
changed over time. Here's where I was in March:

I'd say you're fine using it if it works for you. I find that it's
good for publishing a lot of messages quickly. If you're going to use
it as a consumer, you're better off just doing the minimal work of
using the asynchronous methods because you'll be working with the
asynchronous callback in the blocking connection anyway. I'll be
supporting bug fixes in the 0.9 tree but my focus on Pika and heart is
in a cleaner implementation.

More information about the rabbitmq-discuss mailing list