Umm, then what is the ttr for, if not disaster recovery? reserve then bury solves nothing, because if processing is actually interrupted then I won't get the task back on the queue (like it logically should after ttr seconds).
Anyhow, it would be nice to have it be an option (personally think it should be the default, but hey :) ).. On Mon, Aug 16, 2010 at 1:50 PM, William McVey <[email protected]> wrote: > On Mon, Aug 16, 2010 at 3:22 PM, Dustin Norlander <[email protected]> wrote: >> Seems very odd to enforce workers to keep an open connection while >> process a job.. >> Network stability shouldn't have anything to do with the task queue: > > Personally, I disagree. If I have an outage (whether network outage or > worker machine catching fire), I absolutely do not want jobs stuck > waiting for the host or network to be restored. I think in the face of > an outage, it's entirely appropriate to recover the jobs for > delegation to a new worker to take over the processing. And it also > seems entirely appropriate that the connection to the job broker is as > good as any other form of heartbeat. If you do need disconnected > processing, it would seem that you could reserve, bury and disconnect, > process, and then reconnect to delete the job. > > -- William > > -- > You received this message because you are subscribed to the Google Groups > "beanstalk-talk" group. > 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. > > -- You received this message because you are subscribed to the Google Groups "beanstalk-talk" group. 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.
