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

Answer 1

disclaimer: this comes from a person that never used AMQP or any other similar product before.

Bad documentation is bad. (C# would be a bad if there was no documentation for .Net and C#) So ZMQ might be the best thing out there if you know how to use it, but documentation that exists(not a lot) is quite bad(we are so smart, this is so good, Erlang, blah blah, not a single n-to-n example in guide...).
You say so what, most of the OS projects have bad documentation or none. Yeah but for quite oa few OS projects you can google a ton of stuff(tutorials, examples...). With ZMQ it is : Zero is for documentation. Since Im a C++ dev ill say it like this. Before trying to use ZMQ I thought boost has bad documentation and relatively few examples on the internet. But compared to ZMQ Boost documentation is great and examples are plentiful.

EDIT: to make things more fun(civil war :P): http://www.infoq.com/news/2012/03/Crossroads-IO

Martin Sustrik and Martin Lucina, creators of the original ZeroMQ, have decided to regain control of the project by forking it. The new project, named Crossroads I/O, is being setup to encourage a commercial ecosystem that is better capable of meeting their long term financial needs.

EDIT2: copying and running examples from the guide (cpp version of "A Request-Reply Broker") doesnt work. You can see how good the library development process is good by the fact that they dont have their examples as tests. :P
EDIT3: some of the examples are in v2.*, ofc newest version is v3.2. So again this smells like a rotten unmaintained OS project.

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.

Answer 3

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.