lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: Access is denied on
Date Sun, 27 Aug 2006 20:39:50 GMT

Transplanting this thread off of java-user to discuss a more java-dev 
question I have (below):

> Yonik Seeley wrote:
>> On 8/27/06, Doron Cohen <> wrote:
>>> I plan to submit an update to that patch later today accommodating your
>>> comments (and others); It will most probably retry for IOExceptions (not
>>> analyzing the exception text); also, it would return false if the 
>>> *retry*
>>> for obtain() failed with exception.
>> Lock.obtain(timeout) already has retry/timeout logic around
>> Lock.obtain(), so wouldn't the change to return false on an
>> IOException be sufficient?  User level applications should then use
>> obtain(timeout) rather than obtain() unless they want to do
>> timeout/retry logic themselves.
> I would agree: the retry/timeout logic already exists above so let's 
> just return false on hitting any IOException when calling createNewFile.
> (Doron, this still wouldn't fix the other strange "across the board" IO 
> problems you see on Windows.  I'd really like to reproduce this but so 
> far (running your stress test) I can't -- are you sure it's not a virus 
> checker or something?).

I think on hitting the IOException on, we 
should return false (so timeout/retry logic can handle it).

However we should also message this to the user to  make debugging 
simple (vs just silently swallowing the exception).

But: how to do so?  I like the infoStream that IndexWriter supports, 
but, should we adopt [one of] the Java logging APIs (Apache commons 
logging, java.util.logging, log4j, etc.)?

As far as I can tell Lucene doesn't do so now, so, what's the "right 
way" to let the user know that an IOException occurred and this is why 
the "lock obtain" failed?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message