Chris Hostetter wrote:
: > While it's very tempting to take the attitude of "it's Microsoft's
: > fault for exposing this API" or "it's that software's fault for using
: > this API", doing so will only hurt our users: they either suffer (at
: > best), or find some other search software to use (at worst?).
: If this can be fixed/worked-around in a manner that does not penalize
: users w/o this problem, then that's what we should do.
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.
An exception thrown can be researched and documented in such a way that
application developers can fix it themselves. An exception that is
silently worked arround with a performance penalty will be a ghost in the
machine -- which can do more harm to the Lucene User community at large?
Looking at the patch, I can't help but wonder if this is motivation enough
to create a new WindowsFSDirectory implementation, which attempts to work
arround any/all issues of windows filesystems, with documentation
clarifying what it does and what the performance impacts are?
I think we can have a solution that doesn't do any file renaming.
With the lockless fixes (I'm still working on them...) I've already
removed quite a few renames by having the segments file record
explicitly which generation is current (I needed this for the .del and
norm files anyway). I've also removed the deletable file entirely, so
it doesn't get renamed.
But, I'm still renaming segments_N.new -> segments_N, however I think
we could remove that one by instead creating a separate "done" file, eg
"segments_N.done" or something. So the existence of the "done" file
means the segments_N file can safely be loaded. I haven't tried this
yet but I think such an approach should work and would solve the
concerns around sleep/retry?
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
