3 ms·
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 cur
by FooBarWidget 14y ago
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.
- sneak 14y agoZeroMQ 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.
- deleted 14y ago[deleted]
- FooBarWidget 14y agoAnd then you've made your own broker. At that point why not use an existing, more mature broker?
- sneak 14y agoThe 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.
- FooBarWidget 14y agoI 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.
- rdtsc 14y ago+1 for the carrot muncher here is well
- DomBlack 14y agoZeroMQ 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.