On 9/21/06, Michael McCandless <[EMAIL PROTECTED]> wrote:
Anyway, my first reaction was to change this to use System.currentTimeMillis() to measure elapsed time, but then I remembered is a dangerous approach because whenever the clock on the machine is updated (eg by a time-sync NTP client) it would mess up this function, causing it to either take longer than was asked for (if clock is moved backwards) or, to timeout in [much] less time than was asked for (if clock was moved forwards).
Um, wow... that's thorough design work! In this case, I don't think it's something to worry about though. NTP corrections are likely to be very small, not on the scale of lock-obtain timeouts. If one can't obtain a lock, it's due to something else asynchronously happening, and that throws a lot bigger time variation into the equation anyway. -Yonik http://incubator.apache.org/solr Solr, the open-source Lucene search server --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
