Hacker News Reader

Comment by jrockway | Hacker News Reader

Yeah, don't use REQ/REP.

I used to be a big ZeroMQ fan, but honestly, the library trades sanity for performance and has collapsed in on itself because the code is no longer maintainable. Last I checked, it's being completely rewritten in a different programming language. Maybe the result will be fine, but the core features of retrying connections and remembering dropped messages for clients that disappear temporarily are easy enough to write yourself.

(I do like Mongrel2's use of that feature to allow me to make an HTTP request and then start the backend server. And the right place for this is a library. It's just that ZeroMQ had too many features and too much code.)

View on HN

> Last I checked, it's being completely rewritten in a different programming language.

The rewrite you mention is, I believe, Crossroads I/O ( http://www.crossroads.io/ ). Martin Sustrik was one of the creators of ZeroMQ to begin with.

He's got a writeup as to why he should have used C to begin with ( http://www.250bpm.com/blog:4 ).

Hi, that's Martin Sustrik here. Couple of points:

1. As for lost requests, the right thing to do is to timeout the request and re-send the request if the response haven't been received. This should be done inside 0MQ/XS, however, it's pretty easy to do in the application so nobody so far felt incovenienced by it so much as to implement the feature.

2. As for the implementation language C would have been better than C++, but that's only an implementation detail and of not much interest to 0MQ/XS users.

3. Finally, yes, the 0MQ/XS functionality should be implemented in the kernel. Here's the Linux kernel implementation:

https://github.com/250bpm/linux/tree/sp-linux

Here are the userspace examples:

https://github.com/250bpm/sp-userland

Here's the discussion group:

https://groups.google.com/forum/?fromgroups#!forum/sp-in-lin...

However, the problem with kernel implemetnation is that it is -- obviously -- not multi-platform. Thus we'll need the user-space implementations in the future, at least for obscure operating systems.

> Hi, that's Martin Sustrik here. Couple of points:

Out of curiosity, was it impossible to prevent the fork from happening? I do like the idea of ZeroMQ quite a lot but this can only work if it will end up on kernel level at one point and if two projects compete for that spot that probably does not help its cause much.

The fork was over trademark policy, not any technical matter. So no, it was not possible to prevent it. To avoid trademark restrictions, it was necessary to change the name of the project.

Anyway, there's only one Linux kernel implementation and I am not aware of anyone trying to do the same (except the dubious attempt to get DBus into kernel).

Finally, the ultimate goal of the whole project is to make messaging integral part of the Internet stack. That means standardising the protocols in IETF. And having at least 3 independent implementations makes it almost suitable for fast-tracking.

http://www.crossroads.io/ looks like the sane path to follow after the community implosion of zeromq.

"community implosion" ? Please do share.. I've only been dabbling with ØMQ, but it seems a lot more active than crossroads.

What is the community implosion you're referring to?

It's just that ZeroMQ had too many features and too much code.

Wasn't ZeroMQ supposed to be the simple, lightweight alternative?

I'm feeling better about my decision to ignore all the whole *MQ circus.

Well, zeromq has nothing to do with amqp (rabbitmq as the prototypical example), so there's not much of a circus.

People compare them all the time, including the ZeroMQ people themselves:

http://www.zeromq.org/docs:welcome-from-amqp

It's not really a useful comparison. You can use ZeroMQ to build a lightweight message queue, but if you really need a message queue it would be best to just use a full message queue. ZeroMQ is more of a message passing toolkit.

Did you use something else instead or just decide not to design around message-queues at all?

I switched to iOS development. ;)

Does he sound like the right person to ask about the matter?

He wonders if "wasn't ZeroMQ supposed to be the lightweight alternative" --which means he never bothered to go read the source code or use to find out.

Then he feels "validated" of not using any *mq stuff (besides, say ZeroMQ and RabbitMQ being totally different in scope and implementation), because he read a random comment in this very thread that reads more like a /. flame.

Lastly, he doesn't even do much work (if any) with messaging. From his response below, it seems like he considered messaging options for some project, couldn't figure then out and/or didn't proceed with the project, and does non message-related iOS work now.

Too much code?

0MQ ~15k LOC RabbitMQ ~107k LOC AMQP Qpid ~542k LOC ActiveMQ ~1160k LOC

i'm sorry but comparing 0MQ to these other systems is caca doodoo. i'm telling you as a developer who has on multiple occasions considered using 0MQ it lowers my trust in you as an evangelist for the platform to suggest that this is a relevant or worthwhile comparison to make.

Consider my comment in the context. The comment I was replying to says that 0MQ/XS is not lightweight because it has too much code. That's simply not true and that's what I was alluding to.

> 0MQ ~15k LOC RabbitMQ ~107k

Might want to try this comparison again when 0MQ (or is it xroads?) supports clustering, high availability, durability, web management, federation, & STOMP.

the only circus is the incorrect conflation of 0MQ with actual durable message queue systems.

>I'm feeling better about my decision to ignore all the whole MQ circus.*

Yes, because a random, 1 paragraph (and content-less, at that) comment on a social media site is very good grounds for verifying your technical decision.

(And referring to a series of projects as "circuses" without any deeper knowledge about them besides casual internet mentions, is also very mature).

Do you have an alternative you use?

Reply on news.ycombinator.com