Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <44F20316.7070208@mikemccandless.com>
Date: Sun, 27 Aug 2006 16:39:50 -0400
From: Michael McCandless <lucene@mikemccandless.com>
User-Agent: Thunderbird 2.0a1 (X11/20060724)
MIME-Version: 1.0
To: java-dev@lucene.apache.org
Subject: Re: java.io.IOException: Access is denied on
 java.io.WinNTFileSystem.createFileExclusively
References: <d8050f240608270936y1c2c69c6rb2d05e1e4a09d755@mail.gmail.com>
	 <OFC393C607.2B74353A-ON882571D7.005FC6E4-882571D7.00616057@il.ibm.com>
 <c68e39170608271105h54f4e401mefb592db1f1124a3@mail.gmail.com>
 <44F2019C.3050705@mikemccandless.com>
In-Reply-To: <44F2019C.3050705@mikemccandless.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


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 <DORONC@il.ibm.com> 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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org