-
Notifications
You must be signed in to change notification settings - Fork 25.6k
Fix Leaking Listener in BlobStoreRepository #69110
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
Fix Leaking Listener in BlobStoreRepository #69110
Conversation
We have no guarantees that implementations won't throw a non-IO exception in this spot so we have to make sure to resolve the listener on any exception to not leak it.
|
Pinging @elastic/es-distributed (Team:Distributed) |
| existingListener.onFailure(e); | ||
| }; | ||
| threadPool.generic().execute(() -> doGetRepositoryData( | ||
| threadPool.generic().execute(ActionRunnable.wrap( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not strictly necessary, just for good measure. We do use .wrap in all other calls to doGetRepositoryData as well, just missed it here ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM2, sorry I didn't see this yesterday.
Are there other places where we fail to properly handle non-IO exceptions?
|
Thanks Francisco and David!
I audited the blob store for this and found one spot that has a TODO on it anyway here: elasticsearch/server/src/main/java/org/elasticsearch/repositories/blobstore/BlobStoreRepository.java Line 1052 in 6381ce0
|
Follow-up to elastic#69110. We can't assume that repository implementations will only throw `IOException`. The GCS SDK for example does throw `StorageException` which is not an IO exception so we must handle all exceptions the same way here.
We have no guarantees that implementations won't throw a non-IO exception in this spot so we have to make sure to resolve the listener on any exception to not leak it.
We have no guarantees that implementations won't throw a non-IO exception in this spot so we have to make sure to resolve the listener on any exception to not leak it.
We have no guarantees that implementations won't throw a non-IO exception in this spot so we have to make sure to resolve the listener on any exception to not leak it.
Follow-up to #69110. We can't assume that repository implementations will only throw `IOException`. The GCS SDK for example does throw `StorageException` which is not an IO exception so we must handle all exceptions the same way here.
Follow-up to elastic#69110. We can't assume that repository implementations will only throw `IOException`. The GCS SDK for example does throw `StorageException` which is not an IO exception so we must handle all exceptions the same way here.
Follow-up to #69110. We can't assume that repository implementations will only throw `IOException`. The GCS SDK for example does throw `StorageException` which is not an IO exception so we must handle all exceptions the same way here.
We have no guarantees that implementations won't throw a non-IO exception in this spot
so we have to make sure to resolve the listener on any exception to not leak it.