I've run into this as well. I expected to be able to delete a job from another process, so that I could integrate beanstalkd into a pipeline of workers. I can delete the job as soon as I pull it from the queue, but then of course, I lose the TTR functionality.
I'm guessing it's designed this way so that the job will immediately return to the queue on a client disconnect. But I would much rather let the TTR handle that and have the flexibility to work with jobs using different connections (i.e. from different processes, threads, or greenlets). It can be difficult to find a queue that satisfies all the requirements of the design for a distributed system, and this is really the only issue that would prevent me from using beanstalkd, so I would be very happy to see a solution for it. On Sunday, June 1, 2014 at 3:56:08 AM UTC-4, Keith Rarick wrote: > > On Sun, Jun 1, 2014 at 12:37 AM, Jan Z <[email protected] <javascript:>> > wrote: > > It's not unreasonable to expect that a reservation survives a client > > disconnect/reconnect sequence, and this information really requires some > > digging to discover. > > I agree, this is badly documented. Would you file an issue? > -- You received this message because you are subscribed to the Google Groups "beanstalk-talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/beanstalk-talk. For more options, visit https://groups.google.com/d/optout.
