Ask HN: Has anyone had negative experiences with zeromq?

> "using Python Tornado and it to form an http caching reverse proxy"

It sounds like you should investigate http://mongrel2.org/home

ZeroMQ is used in the lubyk (formerly rubyk) project: http://lubyk.org/en

I've used it and it works great. The only problem I remember encountering was getting it to work with a virtualenv, but that was probably just inexperience on my part.

Before I opened the 0MQ Pandora box I'd given up coding and was happily writing my autobiography. 0MQ seemed like a pleasant way to spend a weekend. But before I knew it, I'd lost control. Days, weeks, months have passed now, all I think about are more subtle and perfect messaging patterns. They flash before my eyes. Weird names and topologies. It doesn't get better, but worse. Soon I'll be coding all nighters, my wife will leave me, my kids will forget me, and all I'll be doing is programming, motherfucker.

Seriously, 0MQ has made network programming fun (again) in a bad, addictive, way. Any design I can think of turns into real working code in a few hours, sometimes days. And I'm using C, a language that isn't normally fun to work in.

Right now, it's multithreaded clients and servers for resilient shared distributed hash maps. Tomorrow, network-wide logging. After that, another message broker. And so on.

Yes, it's a negative experience. I'd like my old lazy life back.

For the love of god, don't try it.

I'm kind of in the same boat. I'm evaluating it right now to see if it'd be suitable for iOS<-->server comms, but it seems more like something you'd use behind the server gateway.

Thing is 0MQ gives you transparent auto-reconnection--but I want to indicate with a spinner when that's happening--and it makes request-reply synchronous--but I already do everything asynchronously in the client anyway. Hmm.

I think Zed Shaw would also vouch for the brilliance of 0mq. He uses it in many places including mongrel2. The one thing he did mention in his pycon presentation was not to expose it to the internet as there are some assertions in the code which cause it to blow up on protocol errors.

It sure seems amazing for what it is. I do with people would stop comparing it to message brokers -- solving for entirely different problems as far as I can tell.

Loggly uses 0MQ extensively and we'd be happy to sit down with you and chat about it. We were the ones that paid the 0MQ guys to bake disk persistance back into the new version. Also, as someone else mentioned, Zed knows it pretty well and he's awesome about taking time to teach what he knows to others.

I have, and it amazes me that everyone speaks so positively of it. I'm not going to argue it's a bad library, or it's not worth investing it, but it's not without its problems. And I certainly don't think it's applicable to all distributed computation use cases.

This post on SO outlines some of the troubles I've had: http://stackoverflow.com/questions/4870814/is-zeromq-product...

A couple of other issues. First, it's really easy to game a ZeroMQ socket. Send it the wrong data, and your application will just fall flat on its face. So you can't run it anywhere that has untrusted computers (e.g. over the Internet).

Another issue I've had is a race condition that occurs when you call recv() before anything is in the queue. The method will continue to block even after it receives something. This is a big deal because it requires some workarounds with bad performance. But I wasn't able to get the jzmq dev team to reproduce it, so it must be something restricted to either OS X or just my system.

FWIW, I think most of the issues are restricted to jzmq, because there's a good deal more complexity running around in that project to overcome the Java <-> C bridge.

The reason I continue to use it anyway is because:

1) It's absurdly useful when it works.

2) The dev team is very responsive.

3) Bugs do get fixed if they can reproduce it. I already have had one issue resolved: https://github.com/zeromq/jzmq/issues/closed#issue/31

As for Tornado, I am in love with that technology. Rather than a framework, it's more like a set of libraries for HTTP communication. That has huge implications, and it feels much more pleasant for me to work with than, say, Django.

I can't say I have a lot of negative experience, but after evaluating it, I've come to the conclusion that it's not the right tool for the job for us. We develop trading systems and I wanted a decent messaging framework for internal non-speed-critical communication between apps. Disclaimer: I had limited time to evaluate it, so I may have some misconceptions about ZMQ, you have been warned.

1. Extensive use of asserts in release builds terrifies me. It's meant to check for conditions that shouldn't happen, but I see users complaining about their apps aborting with assertion failures on ZMQ mailing lists and it comes up fairly frequently in Google. There are a fair bit of asserts for error codes returned from system calls. I don't want a critical process crash because I've used library in a wrong way in a completely different part of the application.

2. Only in 2.1 they've fixed the problem where some messages would not be flushed and be lost if you terminate the process too early. This seems like a fairly common bug for younger projects. Recommended workaround is... calling "sleep" before you exit, which is one of the deadly sins of multithreaded programming! This and above point convinces me that ZMQ isn't as mature enough for me to be comfortable with.

3. Transparent reconnection is good, but some of our applications need to quickly detect that other nodes in the system are missing, which forces me to implement off-band heartbeat mechanism.

4. Threading model seems a bit awkward to me (last I checked). First of all, let me state that I personally believe that a library starting threads behind your back is a Bad Thing (unless it's a framework). ZMQ uses a sender thread that you queue your messages into, yet it forces you to dispatch your receive loop by either blocking read or zmq_poll. If it already starts threads by itself, why not provide a callback?

5. Not really a problem, but a missing feature: no way to demultiplex messages from a stream of messages, so you have to implement it yourself. You can subscribe to a subset of messages on a socket, but can't subscribe to multiple subsets from a single socket.