Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch InternalShardLock from using LockObtainFailedException to a different exception #19978

Closed
dakrone opened this issue Aug 12, 2016 · 1 comment

Comments

Projects
None yet
2 participants
@dakrone
Copy link
Member

commented Aug 12, 2016

According to the documentation for LockObtainFailedException:

This exception is thrown when the <code>write.lock</code> could not be acquired.

We should not use this exception for the in-memory semaphore that's part of NodeEnvironment, we should use a different exception class.

@rmuir

This comment has been minimized.

Copy link
Contributor

commented Aug 12, 2016

+1 hijacking this exception is crying wolf, it freaks me out if i see it, especially if it does not contain the expected contents. Lets please not use it for any other purpose.

@dakrone dakrone self-assigned this Aug 12, 2016

@dakrone dakrone removed the help wanted label Aug 12, 2016

dakrone added a commit to dakrone/elasticsearch that referenced this issue Aug 16, 2016

Switching LockObtainFailedException over to ShardLockObtainFailedExce…
…ption

`LobObtainFailedException` should be reserved for on-disk locks that
Lucene attempts (like `write.lock`). This switches our in-memory
semaphore locks for shards to use a different exception. Additionally,
ShardLockObtainFailedException no longer subclasses IOException, since
no IO is being done is this case.

Resolves elastic#19978
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.