While I think this is not an ideal solution, but for the reasons you mentioned (re invasiveness/ease), I'd be willing to accept it.
I think I would prefer to fix the queuing so that it can't leave an unserviced request. But if the "fix" of waking a thread every now and again is well documented it should be ok for now. I would put a large comment in the thread loop that indicates that we are away of the race and chose to fix it by waking the thread on an interval. It would surely save some future code-detective some time if they want to know why their request sometimes waits for ~10ms on an otherwise idle instance. It may also prevent some future "optimizer" from re-introducing the bug by removing the interval on the conditional wait. On Sun, Sep 11, 2011 at 4:35 PM, John Plevyak <jplev...@acm.org> wrote: > I don't think so as this should be self correcting in a busy system > as Bart pointed out; the main concern is initialization or recovery. > > I'll take care of this... > > john > > On Sun, Sep 11, 2011 at 1:59 PM, Leif Hedstrom <zw...@apache.org> wrote: > >> On 09/10/2011 02:17 PM, John Plevyak wrote: >> >>> This is a race condition which should happen very very infrequently (e.g. >>> once a day >>> on a loaded system perhaps) and it would only be 10msec on an unloaded >>> system, which would >>> make it very very very infrequent (maybe once a year in that case). I >>> agree >>> that 10 msec >>> is long these days, but unfortunately unix-ish systems cannot be counted >>> on >>> to not >>> busy spin when delaying less than 10 msecs. So while I agree with you in >>> principle, >>> in practice 10 msec is probably a safer. >>> >> >> Agreed. So, is there a bug filed for this? Is there an easy fix? John, I'm >> wondering if this is the same problem Yahoo Search was having, where once in >> a while, a cache would go MIA (unavailable) until they restarted the server. >> On their busy boxes, it'd happen after ~2 weeks or so. >> >> -- leif >> >> >
