[rabbitmq-discuss] Pika and threads
Gavin M. Roy
gmr at myyearbook.com
Tue Jul 19 16:09:09 BST 2011
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.
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)
More information about the rabbitmq-discuss