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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
