On Thursday, August 30, 2012 2:58:52 AM UTC+5:45, chadkouse wrote: > > Yeah. That's a hard problem depending on where in the process your > consumer died. You can only delete a job you have reserved and if you > close/reopen the connection to beanstalkd then you lose that client > reservation that it relies on. You will need to code around this in your > consumer just as you would with a transactional db that dies after > committing a transaction but before telling the client it finished. >
The only other way I can think of to handle this is to reserve / delete the job immediately, but the the client has to absolutely guarantee it will be correctly processed, which is tricky, and avoiding that kind of workflow is why I chose beanstalkd in the first place! I guess I was hoping that there was some way I could emulate this behaviour with the existing API - otherwise it seems like a possible solution would be to patch the protocol to allow and 'override' for DELETE, even if it appears the job is reserved to someone else. Even if used incorrectly it shouldn't cause too many issues, since clients already need to handle the chance that they delete too late and find the job has already been put back in ready. Are there any horrible consequences to that approach that I have missed? Cheers, ben -- You received this message because you are subscribed to the Google Groups "beanstalk-talk" group. To view this discussion on the web visit https://groups.google.com/d/msg/beanstalk-talk/-/MUgSze8V-p0J. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/beanstalk-talk?hl=en.
