[
https://issues.apache.org/jira/browse/LUCENE-948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-948:
--------------------------------------
Attachment: LUCENE-948-core-2.2.0.take2.jar
LUCENE-948.take2.patch
Another iteration, to just add more verbosity when infoStream is set.
> Writers on two machines over NFS can hit FNFE due to stale NFS client caching
> -----------------------------------------------------------------------------
>
> Key: LUCENE-948
> URL: https://issues.apache.org/jira/browse/LUCENE-948
> Project: Lucene - Java
> Issue Type: Bug
> Components: Index
> Affects Versions: 2.1
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Attachments: LUCENE-948-core-2.2.0.jar,
> LUCENE-948-core-2.2.0.take2.jar, LUCENE-948.patch, LUCENE-948.take2.patch
>
>
> Issue spawned from this thread:
> http://www.gossamer-threads.com/lists/lucene/java-user/50680
> When IndexFileDeleter lists the directory, looking for segments_X
> files to load, if it hits a FNFE on opening such a file it should
> catch this and treat it as if the file does not exist.
> On NFS (and possibly other file systems), a directory listing is not
> guaranteed to be "current"/coherent. Specifically, if machine #1 has
> just removed file "segments_n" and shortly thereafer machine #2 does a
> dir listing, it's possible (likely?) that the dir listing will still
> show that segments_n exists.
> I think the fix is simple: catch the FNFE and just handle it as if the
> segments_n does not in fact exist.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
