[rabbitmq-discuss] Pika and threads

Tue Jul 19 16:10:41 BST 2011

On Tue, Jul 19, 2011 at 16:09, Gavin M. Roy <gmr at myyearbook.com> wrote:
>  BlockingConnection is now an blocking emulation layer on top of the asynchronous core. It will be maintained but it is not very efficient for synchronous commands.
>
> I am no longer considering it deprecated due to the widespread use and natural inclination of  people to go with it. The notes for this will be updated in the next release.

That's a good news. Thanks!

> On Tuesday, July 19, 2011 at 10:09 AM, Marek Majkowski wrote:
>
>> 2011/7/19 Alex Grönholm <alex.gronholm at nextday.fi (mailto:alex.gronholm at nextday.fi)>:
>> > 19.07.2011 13:37, Marek Majkowski kirjoitti:
>> > >
>> > > Alex,
>> > >
>> > > 2011/7/17 Alex Grönholm<alex.gronholm at nextday.fi (mailto:alex.gronholm at nextday.fi)>:
>> > > >
>> > > > I wanted to use Pika to implement an RPC server using RabbitMQ. I found
>> > > > that
>> > > > this was however not possible because when I process the request in a
>> > > > thread, I have no good way to thread safely send the results back.
>> > >
>> > > Isn't that the point of RPC? To stop the request process/thread until
>> > > the response comes back.
>> >
>> > That way the server could only process one request at a time. Obviously that
>> > is not good enough. My server uses 15 worker threads (possibly processes in
>> > the future) which need to send results back to the client once they are done
>> > processing the request. I solved this by using TornadoConnection, since
>> > Tornado's I/O loop does implement the required functionality
>> > (add_callback()) and uses a proper waking mechanism unlike
>> > SelectConnection's. That way, when a worker thread wants to send its results
>> > back to the client, it can interrupt the I/O loop which then proceeds to
>> > send the data.
>>
>> I'm glad you were able to come up with a sensible solution.
>>
>> > > > The IOLoop lacks a mechanism for interrupting it directly. The best I
>> > > > could
>> > > > figure was setting a timeout of 0, but it might take up to a second for
>> > > > this
>> > > > to happen, considerably adding to the response latency.
>> > > > Why isn't there just a dummy signalling socket that could be used for
>> > > > interrupting the poll?
>> > >
>> > > In the tutorials I was using BlockingConnection:
>> > > http://www.rabbitmq.com/tutorials/tutorial-six-python.html
>> > >
>> > > Is that of any use to you?
>> >
>> > The docs say that BlockingConnection is legacy stuff and should not be used.
>> > Is this no longer the case?
>>
>> I don't know. Loosing BlockingConnection would be a pitty, rabbitmq
>> tutorials are using it :)
>> _______________________________________________
>> rabbitmq-discuss mailing list
>> rabbitmq-discuss at lists.rabbitmq.com (mailto:rabbitmq-discuss at lists.rabbitmq.com)
>> https://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>
>