Is ZeroMQ production ready?

Question

What are your experiences with ZeroMQ as a general purpose messaging middleware?

1. Did you run into any show-stopping bugs or non-obvious "features"? E.g. 2.0 was not flushing messages properly, and the troubleshooting guide seems to give the most terrifying workaround of them all: "sleep(1) before exit".
2. Did the API reduce complexity of applications or did it prove to be troublesome?
3. Is backwards compatibility often broken?

Answer 1

I'm using it for research, so "semi-production". It's a wonderful framework, and the way things are architected certainly make sense once you fully grok it. But I've hit far too many problems to consider it production ready. I'm using jzmq, so some of this might be specific to that.

1. Setting up jzmq on OS X / Eclipse is...not pleasant.
2. Starting the application will occasionally cause an assertion failure in the ZeroMQ C code, so I need to wrap my application in something that checks for this exceptional state.
3. Errors are oftentimes very undescriptive. I've had far too many illegal state exceptions with no explanatory message.
4. There's no support for TLS. This is almost a deal-breaker for me, and I could easily see it ruling out its availability for a number of applications.
5. Documentation is "off". The official guide is nice, but if you have a specific problem, it's usually not helpful. And it takes me longer than usual to find the answers to things when googling around. The mailing list is however pretty active.

BUT, and this is a big but, I can't count how many man-hours it has saved me. This post has a good summary of just a few of the ways it makes life more pleasant.

Answer 2

I am also using ZeroMQ in a "semi-production" environment (prototyping for DARPA). Thus far it has been really excellent for "tying cats together," especially when those cats are written in different languages and live on different machines. The available socket idioms make thinking about a distributed computing problem very straightforward. ZeroMQ's strength is ergonomics: a solid mental model and plentiful language bindings.

Proceed with caution, though, if you are up against hard performance constraints. I'm working on a real-time system and have found that, though ZeroMQ aims to be a high-performance solution, it isn't ready for primetime. I think the architecture that's in place has great potential; it just seems to be hampered by some niggling bugs. I probably should have expected that from a library that has evolved so rapidly, going from 0.0 to 3.0 in a relatively short time. Still, I thought I'd get a drop-in replacement for my own, hand-tooled protocol stack and immediately hit some deal-breakers. If you decide to go with ZeroMQ, just keep in mind that you are working well above the transport layer, and if performance is less-than-desirable there's little you can do about it.

That being said, the chatter on the mailing list and IRC channel is pretty great. The devs seem genuinely interested in building something that's completely state-of-the-art. They love it that their library has buzz and is getting used for serious, interesting things. They're busy people, so don't expect a ton of hand-holding. If you've got a real problem, though, they are eager to know what's going on.

Bottom line: A great Swiss army knife for everyday distributed computing problems. Be cautious if you're looking for bleeding-edge performance; it's at least one major release off. Still, the future is looking great for this project, so use it and support it.