Transplanting this thread off of java-user to discuss a more java-dev
question I have (below):
http://www.gossamer-threads.com/lists/lucene/java-user/39382
Yonik Seeley wrote:
On 8/27/06, Doron Cohen <[EMAIL PROTECTED]> 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 java.io.File.createNewFile, 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?
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
