GitHub user pgerber opened a pull request:
https://github.com/apache/lucene-solr/pull/374
Improve detection of recreated lockfiles
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
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/pgerber/lucene-solr locking
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/lucene-solr/pull/374.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #374
----
commit c46de23fd4a585cc00bfe4f2703ef65d54faa4ed
Author: Peter Gerber <peter@...>
Date: 2018-04-19T15:09:41Z
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
----
---
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
