[rabbitmq-discuss] Pika and threads

[Marek Majkowski]

2011/7/19 Alex Grönholm <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>:
>>>
>>> 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 :)