lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter (JIRA)" <>
Subject [jira] [Created] (SOLR-12334) Improved detection of recreated lock files
Date Wed, 09 May 2018 14:16:00 GMT
Peter created SOLR-12334:

             Summary: Improved detection of recreated lock files
                 Key: SOLR-12334
             Project: Solr
          Issue Type: Improvement
      Security Level: Public (Default Security Level. Issues are Public)
            Reporter: Peter

Just wanted to let you know, in accordance to the Contribution Guidelines, that I created
a pull request on GitHub ([]
h1. Commit Message

Improve detection of recreated lock files

I've been running into issues with the detection of deleted and then
recreated files when using GlusterFS. Since, on most platforms, there
are more reliable ways to detect recreated files, I decided improved
the detection of such files.


As part of LUCENE-6508 [3] detection of recreated files was added.
In such a case, another instance may have obtained lock on the newly
created file. This isn't something that should happen on a properly
configured Solr instance but there is a good chance for this
happening when an index is shared by multiple instances that use a
different locking mechanism.


On platform that support it, fileKey() [1] is now used. On Unix-like
systems this key consists of the device ID and and inode. For locks
that keep the lock file open, this should ensure we detect recreation
since no two files can have the same device ID and inode even if the
last hard link has been removed already. Other locks, that don't keep
the file open, should still detect recreation at a low error rate.

Platforms without fileKey() support keep using the creation timestamp
or modification timestamp (subject to availability) [2].


This message was sent by Atlassian JIRA

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

View raw message