Hacker News Reader

Comment by FooBarWidget | Hacker News Reader

I would not use ZeroMQ for anything but the most non-critical queues. ZeroMQ is not persistent: if your server crashes you lose all your queue contents.

My current favorite is RabbitMQ. It has improved steadily over the years, performs pretty well and very easy to setup.

View on HN

ZeroMQ is a messaging library only.

There is nothing stopping you from using ZeroMQ to build a daemon that implements a persistent queue— in fact, I have, several times. It's very simple.

And then you've made your own broker. At that point why not use an existing, more mature broker?

The zero in ZeroMQ is because brokerlessness is a strength in some aspects.

A broker can be an SPOF, for instance. 0MQ makes it easy to do shared-nothing.

I know what ZeroMQ does. But you argue that a one can easily write a broker on top of ZeroMQ that provides persistency, but that invalidates your biggest reason of using ZeroMQ, namely brokerlessness.

Besides SPOF is not an argument. All serious brokers have supported clustering and failover for quite a while, and they support persistency. I don't see a good reason why you may want to write a ZeroMQ-based broker instead of just using RabbitMQ.

ZeroMQ is not persistent: if your server crashes you lose all your queue contents.

With my requirements if I haven't processed the message quick enough then I don't care if it gets lost, as it would already be outdated data.

+1 for the carrot muncher here is well

Reply on news.ycombinator.com