So - this has nothing to do with NSQ - just my $0.02. Maybe zeromq has changed a lot since I looked at it quite a while back. The trouble we constantly ran into was zeromq is really just a fancy socket library - this means that you have to program all the logic yourself if you want certain things to happen if messages cannot be delivered (e.g. log the fact at a minimum), or get queued abnormally long, or get acks from the other side etc.
Which is fine - you have to do all this yourself with plain sockets unless you just need a fire & forget system(albeit with the smarts of retrying and failover and some convenience of pub-sub). However we ran into problems where we could not get the info out of zmq that we wanted, such as the fact a peer had failed, the current rtt, and other things - leaving the gain we'd get from zmq at practically nothing.
Comments
So - this has nothing to do with NSQ - just my $0.02. Maybe zeromq has changed a lot since I looked at it quite a while back. The trouble we constantly ran into was zeromq is really just a fancy socket library - this means that you have to program all the logic yourself if you want certain things to happen if messages cannot be delivered (e.g. log the fact at a minimum), or get queued abnormally long, or get acks from the other side etc. Which is fine - you have to do all this yourself with plain sockets unless you just need a fire & forget system(albeit with the smarts of retrying and failover and some convenience of pub-sub). However we ran into problems where we could not get the info out of zmq that we wanted, such as the fact a peer had failed, the current rtt, and other things - leaving the gain we'd get from zmq at practically nothing.