3 ms·
this recent mq hype is really about the unification of a directory server, a wire protocol and a reliable (or not) message transfer scheme just like the good ol
by plq 16y ago
this recent mq hype is really about the unification of a directory server, a wire protocol and a reliable (or not) message transfer scheme just like the good old smtp. once one sets up a proper directory solution (ldap) and uses thrift for serialization, the need for a messaging daemon goes away -- every publisher can keep an (optionally) persistent queue however they want.. so the mq becomes just a library.
it seems to me that imatix guys have been there, done that and saw that mq-as-library was the way to go for a more efficient and reliable distributed transaction processing system. http://www.zeromq.org/whitepapers:brokerless http://www.zeromq.org/whitepapers:brokerless is an interesting read in this regard.
- shykes 16y agoI am going to read this avidly. ZeroMQ's broker-less approach seemed like more work for me. This is an opportunity to reconsider my position. We use an AMQP stack and the complexity seems somewhat unjustified. On the other hand, it's good to have a standard, even if it's not perfect. Django+celery is pretty kick-ass, and I would have to give it up if I moved away from AMQP.
- dhruvbird 16y agoCelery is pretty cool in it's own way. It is like the appengine Task Queues rather than message queues in general.
- dhruvbird 16y agoI mostly agree with you taming of the problem statement. However, clients being clients shouldn't be taken as nodes which can handle more than what the programmer provisioned for, Having a queue library sitting on them means some more load as far as that machine goes. Besides, there are cases where you would want to continue operating even if your clients went down.