lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert engels <>
Subject Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
Date Thu, 14 Sep 2006 05:05:59 GMT
Even though I don't agree with this patch... 100ms is WAY TOO long  
for a highly interactive index.

On Sep 13, 2006, at 11:52 PM, Doron Cohen wrote:

> Hoss Man commented on LUCENE-665:
>> FYI: on the surface FSDirs_Retry_Logic_3.patch scares me because in
>> many cases wait/retry logic is impossed inside of catch(Throwable)
>> blocks ... that's seems a little too broad to me.
> Chris Hostetter <> wrote on 13/09/2006  
> 14:57:29:
>> I agree in spirit, but the caveat to that is that if we silently
>> work arround the problem at a very low level, it can lead to  
>> situations
>> were lucene is constaintly waiting and retrying every single  
>> operation --
>> which may lead people to assume Lucene itself is slow just because of
>> their environment.
> We could retry only for IOExceptions, possibly only those specifying
> "access denied" in their root cause message. This would narrow the  
> range of
> cases the retry logic is applied. In fact the first version had this
> narrowing logic, but it was removed after a comment uncomfortable with
> relying on specific exception message. Narrowing this way the retry is
> applied only in cases of this unexpected "access denied" error, and:
>   - these cases are very rare
>   - retry is for 100ms
>   - current alternative is (possibly) a corrupted index
> A solution without retry, if found, is far better of course - but  
> until
> then, it is encouraging that similar retry logic is working for other
> projects, and that the retry is both rare and short.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message