lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: [jira] Commented: (LUCENE-665) temporary file access denied on Windows
Date Wed, 13 Sep 2006 22:05:16 GMT
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, 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?


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

View raw message