3 ms·
That is correct, beanstalkd was an inspiration for this project. I've even credited it here: https://github.com/iamduo/workq#credits https://github.com/iamduo/w
by iamduo 10y ago
That is correct, beanstalkd was an inspiration for this project. I've even credited it here: https://github.com/iamduo/workq#credits https://github.com/iamduo/workq#credits. Could you describe what the use case of the move-tube command was? More specifically on what it was trying to accomplish within the state machine?
Internally Workq, for simplicity, does not have any separates "tubes" however. Just a job pinned by its name.
- jalfresi 10y agoThe idea was that you would reserve a job in a tube, do some work, then move that job to another tube upon success atomically, without the need to delete the job, then create the job in the new target tube. The problem is that if you create the job in the new tube before deleting, the TTL could kick in and return the job to the original tube, meaning you have the same job in both tubes. The other alternative is to delete the job then put it in the target tube. However, if your worker process dies during this step, you may end up losing the job.
- snovv_crash 10y agoIt sounds like what you need is some sort of transaction support so that deletes and adds only happen if both succeed.
- jalfresi 10y agoWhich would make things a lot more complicated - vs. issuing a move command on a job id where the server would be responsible for making sure the atomic move succeeded. It's not a difficult feature to implemented (in fact if I recall there is a pull request open for this feature in beanstalkd) and IMHO would open up a lot of interesting use cases.
- iamduo 10y agoIs there a reason why there aren't 2 types of jobs? One for each stage? You mentioned the first stage there is some work performed, then it sounds like you need to pass on the work again to another worker for the second stage.