Nicholas Piël wrote a great blog introducing readers to the basic concepts of ZeroMQ.
ZeroMQ is a messaging library, which allows you to design a complex communication system without much effort. It has been wrestling with how to effectively describe itself in the recent years. In the beginning it was introduced as ‘messaging middleware’ later they moved to ‘TCP on steroids’ and right now it is a ‘new layer on the networking stack’.
I had some trouble understanding ZeroMQ at first and really had to reset my brain. First of all, it is not a complete messaging system such as RabbitMQ or ActiveMQ. I know the guys of Linden Research compared them, but it is apples and oranges. A full flexed messaging system gives you an out of the box experience. Unwrap it, configure it, start it up and you’re good to go.
ZeroMQ is not such a system at all; it is a messaging library to be used programmatically. It basically gives you a pimped socket interface allowing you to quickly build your own messaging system.

Hi Martin !
I have some problems in shutting down a (busy) system.
Imagine some different services, each with multiple instances and (of course) partially using the others. Some requests are splitted to smaller requests to other services.
If trying to shutdown this system from a central point, you can not know, in which state each (maybe remote) service currently is (waiting, receiving, working, replying), so the only way is to request a shutdown of the worker threads via a message … consequent and easy thing ;o)
But alas there is no way to ensure, that there is no message in the queue behind the shutdown request. What happens to these left overs, after the last worker has gone home? The internal dispatcher, that filled the queue is in my case your queue device (following the "multithreaded server" example).
What I'm looking for, is some way to
a) close the listening end of the queue device to hinder new messages from arriving
b) count the messages, that are waiting on the outgoing end due to missing workers
c) read those messages (for putting them to DB for a later restart)
Could your "swap to disk" feature be used for not loosing messages during shutdown? Is there some other way to get hands on undelivered messages? The only way that comes to my mind is to set up some a special "saver service", that connects to each service's worker-end sucking the messages from the queue, but this would be a humble and complicated solution and also not secure: to hinder further messages from arriving at the "service-end", the context must be torn down and that also kills the "worker-end", making it impossible to empy the queue from "the outside".
I already have a dispatcher service, that splits messages that MUST be saved (saving the request to DB, forwarding it to the proper service and saving the answer again) from those, that only have informational character and can be dropped in case of shutdown (just forward and forget), but I'd like to get rid of this thing using "onbord" features to make the messages really crash safe.
Suggestions ?
;o)
kind regards
Synopsis