Skip to content

Conversation

@original-brownbear
Copy link
Contributor

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.
@elasticmachine elasticmachine added the Team:Distributed (Obsolete) Meta label for distributed team (obsolete). Replaced by Distributed Indexing/Coordination. label Feb 17, 2021
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-distributed (Team:Distributed)

existingListener.onFailure(e);
};
threadPool.generic().execute(() -> doGetRepositoryData(
threadPool.generic().execute(ActionRunnable.wrap(
Copy link
Contributor Author

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 ...

Copy link
Contributor

@fcofdez fcofdez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 👍

Copy link
Contributor

@DaveCTurner DaveCTurner left a 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?

@original-brownbear
Copy link
Contributor Author

Thanks Francisco and David!

Are there other places where we fail to properly handle non-IO exceptions?

I audited the blob store for this and found one spot that has a TODO on it anyway here:

but won't cause trouble in production when asserts are off. I'll open a follow-up to clean up that TODO so that we get clean logging there as well if we run into this problem on a delete.

@original-brownbear original-brownbear merged commit c7dca01 into elastic:master Feb 19, 2021
@original-brownbear original-brownbear deleted the fix-leak-listener-get-repo-data branch February 19, 2021 21:54
original-brownbear added a commit to original-brownbear/elasticsearch that referenced this pull request Feb 24, 2021
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.
original-brownbear added a commit to original-brownbear/elasticsearch that referenced this pull request Feb 24, 2021
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.
original-brownbear added a commit to original-brownbear/elasticsearch that referenced this pull request Feb 24, 2021
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.
original-brownbear added a commit to original-brownbear/elasticsearch that referenced this pull request Feb 24, 2021
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.
original-brownbear added a commit that referenced this pull request Feb 24, 2021
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.
original-brownbear added a commit that referenced this pull request Feb 24, 2021
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.
original-brownbear added a commit that referenced this pull request Feb 24, 2021
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.
original-brownbear added a commit that referenced this pull request Feb 25, 2021
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.
original-brownbear added a commit to original-brownbear/elasticsearch that referenced this pull request Feb 25, 2021
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.
original-brownbear added a commit that referenced this pull request Feb 25, 2021
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.
@original-brownbear original-brownbear restored the fix-leak-listener-get-repo-data branch April 18, 2023 20:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

>bug :Distributed Coordination/Snapshot/Restore Anything directly related to the `_snapshot/*` APIs Team:Distributed (Obsolete) Meta label for distributed team (obsolete). Replaced by Distributed Indexing/Coordination. v7.11.2 v7.12.0 v7.13.0 v8.0.0-alpha1

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants