Hi Jurian, Here's my advice for dealing with failed jobs: http://xph.us/2010/05/02/how-to-handle-job-failures.
Instead of adding features to beanstalkd to handle other things (such as logging stack traces, or tracking the application's long-term state), it's better to keep beanstalkd itself focused on scheduling work to be done, and leave those other things to other tools. If you have a work item that has two separate phases of execution, and those phases can fail independently, it might make sense to break it apart into two jobs. Having said all that, we definitely need ways to get better visibility into beanstalkd's internal state while it's running in production. -- 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.
