Hello, in the last couple of months I've been working on a message queue of the kind you describe, which is, one that is more biased about providing a number of features already built in inside the broker itself, instead of delegating it to the client. I understand the case for the other approach taken by NSQ and other systems, it's just a matter of what you want to do.
However while my queue project supports persistence, synchronous replication, delayed jobs, at least once and at most once delivery semantics, automatic federation, there is one thing I don't support in the list of features you mentioned: ordering. And I believe there is a strong argument for not supporting ordering in certain kinds of message queues.
By implementing only a weak form of ordering (approximated wall-clock ordering, so that, usually jobs are served in roughly insertion order) we gain: availability (as in CAP, the system can continue with a single node), latency (even in the case of synchronous replication, you need to care just for a message to be replicated into N nodes, regardless of what those N nodes are), and functionality (the queue can auto-reissue messages after a specified retry-time, so at-least-once delivery is trivial to accomplish for consumers and producers). Depending on how the system is designed, to give up strict ordering also wins you scalability.
So I agree about your reasoning but my feeling is that message ordering is a big point that really changes how a message queue is shaped. My bet is that there are many problems where ordering is not needed but all the other features are.
Is your queue project published anywhere? Why did you choose to support persistence? I'm dying for a messaging library that supports only brokerless publish/subscribe with QOS support, request/reply and discovery. On top of that I want to build a persistence layer supporting 'retry' and 'replay' operations; this would allow me to build highly decoupled components, with the ability to do maintenance operations (retry) and rebuild/debug/analyse/spike environments easily (replay), a model which I find supports the type of back-end business applications I build very well.
DDS supports all of this including the QOS layer, but no request/reply unfortunately. The existing open source DDS implementations are massive code bases that I wouldn't dare go near to attempt extending, and DDS is heavily based on IDL, which I'd prefer avoiding. If I had the messaging library I could do the QOS + persistence layer, but so far I haven't seen anything that ticks all the boxes (ZMQ has the raw capabilities but I'd need to build out the publish/subscribe and request/reply protocol, which I honestly don't have the time/skill to do.)
Hello, my project is still not public (but will be, BSD licensed, in a matter of a few months hopefully). However it is not broker-less, it's a cluster of instances that you talk via a network protocol. While messages are made durable via synchronous replication (or async, if you want), I'm adding persistence in order for single datacenter setups to be viable. However it is possible to turn off persistence.
However while my queue project supports persistence, synchronous replication, delayed jobs, at least once and at most once delivery semantics, automatic federation, there is one thing I don't support in the list of features you mentioned: ordering. And I believe there is a strong argument for not supporting ordering in certain kinds of message queues.
By implementing only a weak form of ordering (approximated wall-clock ordering, so that, usually jobs are served in roughly insertion order) we gain: availability (as in CAP, the system can continue with a single node), latency (even in the case of synchronous replication, you need to care just for a message to be replicated into N nodes, regardless of what those N nodes are), and functionality (the queue can auto-reissue messages after a specified retry-time, so at-least-once delivery is trivial to accomplish for consumers and producers). Depending on how the system is designed, to give up strict ordering also wins you scalability.
So I agree about your reasoning but my feeling is that message ordering is a big point that really changes how a message queue is shaped. My bet is that there are many problems where ordering is not needed but all the other features are.