Disque is definitely exciting, and looks like it can replace RabbitMQ, which has serious flaws in its clustering design. I'm looking forward to trying it out. However, if some constructive criticism is permitted, I have to say that, having written distributed applications for many years, I have come to dislike the "classical" push/pop queue data model: * Acking is a bad idea. It requires the broker to manage a lot of…
Kafka has a different data model which works for some scenarios, but not others. We attempted to use Kafka as part of a job management system, where long-running jobs were scheduled and workers consumed partitions, but what we found was that since consumers work on partitions, a long-running task could block an entire partition's worth of work, with no way to migrate it to another partition. Kafka works really well w…
Disque 1.0 RC1 is out
21–30 of 54 posts
Re: Disque 1.0 RC1 is out
#22Is there a product-ready alternative to Disque?
I've been using Sidekiq for the past 2 years, and deem it as production ready. It does force you to use Redis and Ruby though.
Re: Disque 1.0 RC1 is out
#23Earlier quoted context omitted.
I would argue that job management is unrelated to messaging, at least according my loose definition of a task that: * Has a well-defined lifetime — unstarted, running, paused, completed successfully, or failed; * Is executed from some kind of parameterized "job specification" that describes its inputs and desired behavior; * Has state data (e.g., completion % progress, log output, metrics, transactional continutation…
Sure, that's actually very similar to the the system we built internally. But I don't see how Kafka as a messaging layer helps in your system, either. Presumably, the consumers won't advance their offset in their partition until the job is done, because they are not ready to start a new job. So you will still get the same blocking behavior. In addition, I don't see how you implement priority in a system like this, si…
Re: Disque 1.0 RC1 is out
#24Earlier quoted context omitted.
Kafka has a different data model which works for some scenarios, but not others. We attempted to use Kafka as part of a job management system, where long-running jobs were scheduled and workers consumed partitions, but what we found was that since consumers work on partitions, a long-running task could block an entire partition's worth of work, with no way to migrate it to another partition. Kafka works really well w…
I would argue that job management is unrelated to messaging, at least according my loose definition of a task that: * Has a well-defined lifetime — unstarted, running, paused, completed successfully, or failed; * Is executed from some kind of parameterized "job specification" that describes its inputs and desired behavior; * Has state data (e.g., completion % progress, log output, metrics, transactional continutation…
Re: Disque 1.0 RC1 is out
#25It's always refreshing to hear such good programmers acknowledging how hard building complex systems is.
Re: Disque 1.0 RC1 is out
#26> However I’m not living into the illusion that I got everything right in the first release, so it will take months (or years?) of iteration to really reach the operational simplicity I’m targeting. It's always refreshing to hear such good programmers acknowledging how hard building complex systems is.
Re: Disque 1.0 RC1 is out
#27Earlier quoted context omitted.
I've been using Sidekiq for the past 2 years, and deem it as production ready. It does force you to use Redis and Ruby though.
I'm building a node.js application now and WISH we had something half as good as Sidekiq written in Javascript.
Re: Disque 1.0 RC1 is out
#28Re: Disque 1.0 RC1 is out
#29Earlier quoted context omitted.
I'm building a node.js application now and WISH we had something half as good as Sidekiq written in Javascript.
How would you say it compares to something like Celery?
It worked with redis and it worked well.
Re: Disque 1.0 RC1 is out
#30Is there a product-ready alternative to Disque?
It seems like Disque is a "simplified" Kafka, or a more vertically purposed Redis. It seems that it differs from RabbitMQ significantly because rabbit requires a queue to push the messages in, while Disque allows jobs to be pushed independently of consumers being setup.