Peter created SOLR-12334:
----------------------------
Summary: Improved detection of recreated lock files
Key: SOLR-12334
URL: https://issues.apache.org/jira/browse/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
([https://github.com/apache/lucene-solr/pull/374).]
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.
Background:
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.
Implementation:
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].
[1]:
https://docs.oracle.com/javase/8/docs/api/java/nio/file/attribute/BasicFileAttributes.html#fileKey--
[2]:
https://docs.oracle.com/javase/8/docs/api/java/nio/file/attribute/BasicFileAttributes.html#creationTime--
[3]: https://issues.apache.org/jira/browse/LUCENE-6508
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
