launchpad-dev team mailing list archive

[Robert Collins <robert.collins@xxxxxxxxxxxxx>]

On Wed, Jun 15, 2011 at 12:45 AM, Gavin Panella
<gavin.panella@xxxxxxxxxxxxx> wrote:
> On 14 June 2011 12:18, Robert Collins <robertc@xxxxxxxxxxxxxxxxx> wrote:
> [...]
>> Theres a lot of buzz and review and comparisons between mq's at the
>> moment. 0mq and rabbitmq both consistently show up.
>
> 0mq isn't really a queuing system afaict, at least not in the sense
> that RabbitMQ is a queuing system. There's no persistence for one
> thing. The website claims, amongst other things, that it is a "socket
> library that acts as a concurrency framework", and that it can
> "connect N-to-N via fanout, pubsub, pipeline, request-reply". So, it's
> got some routing aspects, but I it's lower level than RabbitMQ or
> Burrow. However, it might fit some problems very well (waking up
> daemons for example).

I highly recommend reading http://zguide.zeromq.org/page:all - It's
long but a fascinating walk through the various interactions and
failure modes and use cases for queues. 0mq does have some basic
persistence (the swap feature + names subscribers) built in for the
pub-sub case.

> Mongrel2 <https://github.com/zedshaw/mongrel2> is an interesting
> system that uses 0mq heavily - it serves HTTP and uses 0mq to talk to
> the services behind it. It doesn't enforce a request/response model;
> any back-end service can reply to the client by virtue of 0mq's
> routing. Mongrel2 is very happy with long-polls, and groks WebSocket
> and JSSocket (via Flash I think) out of the box. Perhaps there's
> something to be learned from it.

I'd actually quite like to look -real-hard- at building LP from
mongrel2. I think it would make a lot of things we struggle with
really quite easy. OTOH I don't want to start over; for now, for me at
least, its in the future pile. Interestingly, the 0mq docs link to
mongrel2, so at least from the perspective of the 0mq authors mongrel2
has legs.

> Also, Aaron brough up Kestrel as an alternative in a previous thread,
> and I collected some excerpts from Kestrel's README a while back:

Yes, kestrel is also very interesting. It implements persistence but
not fail over.

I think we need a better model for analysing our needs around queues
and HA; I'm going to stab at that in a separate thread.

-Rob