You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We currently protect against multiple deletions by acquiring the Engine's writelock, however, we should also ensure that we acquire the write.lock write lock before deleting a shard to ensure that we are the only node writing to the directory.
This will prevent nodes that shared a filesystem from modifying the shard directory in the event that they cannot communicate, assuming that the shared filesystem's locking semantics work correctly.
The text was updated successfully, but these errors were encountered:
In `NodeEnvironment.deleteShardDirectoryUnderLock`, we will now attempt
to acquire, then release, the `write.lock` file for the Lucene index in
question to ensure that no other `IndexWriter` has the directory open
before deleting the data.
Note that the `write.lock` file must be released before the actual
deletion in order to allow the directory to be deleted.
Fixeselastic#11097
In `NodeEnvironment.deleteShardDirectoryUnderLock`, we will now attempt
to acquire, then release, the `write.lock` file for the Lucene index in
question to ensure that no other `IndexWriter` has the directory open
before deleting the data.
Note that the `write.lock` file must be released before the actual
deletion in order to allow the directory to be deleted.
Fixeselastic#11097
In `NodeEnvironment.deleteShardDirectoryUnderLock`, we will now attempt
to acquire, then release, the `write.lock` file for the Lucene index in
question to ensure that no other `IndexWriter` has the directory open
before deleting the data.
Note that the `write.lock` file must be released before the actual
deletion in order to allow the directory to be deleted.
Fixes#11097
We currently protect against multiple deletions by acquiring the Engine's writelock, however, we should also ensure that we acquire the
write.lock
write lock before deleting a shard to ensure that we are the only node writing to the directory.This will prevent nodes that shared a filesystem from modifying the shard directory in the event that they cannot communicate, assuming that the shared filesystem's locking semantics work correctly.
The text was updated successfully, but these errors were encountered: