4 ms·
It seems to offer the same feature set as beanstalkd. We have been using beanstalkd for years to process gazillions of jobs without an issue and I guess many r
by fasteo 10y ago
It seems to offer the same feature set as beanstalkd.
We have been using beanstalkd for years to process gazillions of jobs without an issue and I guess many readers are in the same position.
Why would I choose Workq over beanstalkd ?
- iamduo 10y agoWorkq is similar to beanstalkd and was modeled after many of its concepts especially TTR and reserve (https://github.com/iamduo/workq#credits https://github.com/iamduo/workq#credits). The one feature which may not be obvious yet is the ability for workers to mark a job successfully completed or failed with a result and then retrieve it later. The workflow looks like this: * Client A: Backgrounds a Job A * Client A: Backgrounds a Job B * Client A: Backgrounds a Job C ---- * Worker A: Picks up Job A + Completes * Worker B: Picks up Job B + Completes * Worker C: Picks up Job C + Completes ---- * Client A: Picks up the result for Job A,B,C. This allows a single client to concurrently process multiple jobs within a single process and retrieve its result. This is what I like to call "Gearman mode"[0], as it was modeled after that project also. Useful in languages that do not have well defined concurrency. This is a niche use case and may not be needed by everyone, but very useful as soon as you need it. This will become more obvious when I have clients for these languages. Lastly there are some subtle enhancements such as retry support and synchronous processing (submit and wait for result). Thanks for the great question. This is a very popular question and I will FAQ it. [0] http://gearman.org http://gearman.org