[rabbitmq-discuss] Integrating Pika into Tornado

Fri Jul 2 15:06:03 BST 2010

Andrea,

Thanks for the code, it's pretty interesting.

1. Could you publish the code on github?
2. The meat is in client.py, but I don't really get it. Is it an
object that shares interface with connection.py/Connection?
3. AMQPClient.connect is still blocking, right?
4. for example in send_method, aren't you afraid that
self._stream.write() can fail to write all the data to the buffer?
5. I love the "abc" line in close() :)

I'm very much interested in getting something like that working!

Cheers,
  Marek Majkowski

On Thu, Jul 1, 2010 at 15:10, Andrea Corbellini
<corbellini.andrea at gmail.com> wrote:
> Hello everybody,
>
> Recently I've started to work on a project to make Pika work with the
> Tornado web server, and I would like receive some feedback from you
> before proposing something for merging. The approach I've used
> consists of making Pika more event-based. Since code is better that
> words, I've attached what I've done so far (there's also a test
> script). As you will see, I haven't touched Pika itself yet, instead
> I've written a quick and dirty hack based on the library, rewriting
> just the relevant parts.
>
> There are two main steps that needs to be done in order to have
> something ready to land into the development mainline. First of all,
> the `Connection` and `ChannelHandler` classes should be partially
> rewritten in order to make them event-oriented. Then, the asyncore and
> the blocking adapters needs to be rewritten in order to make them work
> with the new code.
>
> The first step is easy: I've already done most of the work. The only
> thing that should be done is to replace the calls to
> IOStream.read_bytes() and IOStream.write() with two new functions that
> should be overridden by the various adapters. Also, it'd be useful to
> add a `callback` argument to methods such as `send_frame`,
> `wait_for_open` and so on.
>
> The second step instead requires a bit more work. The things to do
> are: make the current adapters more event-based and let them use the
> two new functions.
>
> So, basically, the current flow:
>
> connect -> drain_events() -> handle frame
>
> will be changed in order to become:
>
> connect -> [wait for data] -> callback1 -> [wait for data] -> callback2 -> ...
>
> where "[wait for data]" depends on the adapter (e.g.: the Tornado's
> adapter will use IOLoop, the blocking adapter will read directly from
> the socket).
>
>
> So, that's my propose. I'd happy to answer any of your questions and
> to receive any feedback from you.
>
> Thanks,
> Andrea
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>