You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Michael McCandless (JIRA)" <ji...@apache.org> on 2007/07/03 13:31:04 UTC

[jira] Created: (LUCENE-948) Writers on two machines over NFS can hit FNFE due to stale NFS client caching

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


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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


[jira] Resolved: (LUCENE-948) Writers on two machines over NFS can hit FNFE due to stale NFS client caching

Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/LUCENE-948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael McCandless resolved LUCENE-948.
---------------------------------------

    Resolution: Fixed

Fixed on trunk (2.3).

> 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
>             Fix For: 2.3
>
>         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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


[jira] Updated: (LUCENE-948) Writers on two machines over NFS can hit FNFE due to stale NFS client caching

Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
     [ 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.jar
                LUCENE-948.patch

Attached patch & new 2.2.0 JAR that has this fix.

> 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.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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


[jira] Updated: (LUCENE-948) Writers on two machines over NFS can hit FNFE due to stale NFS client caching

Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
     [ 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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


[jira] Updated: (LUCENE-948) Writers on two machines over NFS can hit FNFE due to stale NFS client caching

Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/LUCENE-948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael McCandless updated LUCENE-948:
--------------------------------------

    Fix Version/s: 2.3

> 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
>             Fix For: 2.3
>
>         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: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org