On Sat, Jan 10, 2009 at 03:45:26PM -0800, Keith Rarick wrote: > > The point of the binlog is to protect against data loss during system > failures (power outages, hardware failures, etc). So if there is an > error writing to the binlog (say the disk is full), the client must be > notified that there was a problem and the data is not safe. The only > way to do this in the existing protocol is to return an error message > (and delete the job from memory). > > A possible counter-argument to this is that beanstalkd should try hard > to continue providing service even if the disk fails, thus giving > better availability overall. It is entirely possible for beanstalkd to > continue operating in memory-only mode in such a situation. However, I > think this breaks the contract that a binlog is supposed to uphold, > especially because there's no way to notify the client that its job > exists in an "unsafe" memory-only condition. I think the proper way to > handle high-availability needs is with redundant servers, while > individual servers stay honest and fail when appropriate.
I think it should fail with an error if the disk is full. If beanstalkd is started with the binlog option on, then I think you can make the assumption that the person running beanstalkd wants a failure if the binlog cannot be used. On the other hand, if the binlog option is not used, then its normal operations. > This honesty policy also preserves atomicity of queue operations -- > they either completely succeed or completely fail. > > So, which error message to return? Possibilities include: > > 1. INTERNAL_ERROR for all errors > 2. OUT_OF_MEMORY for full-disk and INTERNAL_ERROR for other (unexpected) > errors > 3. invent one or more new responses > > Strictly speaking, we shouldn't introduce new error messages during > 1.x, though well-written clients (which, in this case, includes all > libraries ever announced on this mailing list) will do something > sensible with any unexpected server response. > > I'm leaning toward option 2 above, to play it safe. I think it'll be > useful for clients to distinguish full-disk from other error > conditions. A full disk should be by far the most common error, and > it's really the only one a sysadmin has control over. > > Thoughts? I like the idea of (2) and in the documentation state that OUT_OF_MEMORY actually means OUT_OF_RESOURCES, which can mean OUT_OF_DISK if the -b is used and that in the next version of the protocol there will be an alteration. Probably splitting MEMORY and DISK into two different errors? enjoy, -jeremy -- ======================================================================== Jeremy Hinegardner [email protected] --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
