-
Notifications
You must be signed in to change notification settings - Fork 17
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
OpenTelemetryClientFilter causes memory leak #344
Comments
I'll have a look. |
Related issues I've found: |
Yes, I remember having this issue before but never invested the time to fix it. Unfortunately, we don't have a good way to fix it (if any). From what I investigated, I couldn't find a way to catch the Exception and close the trace in RESTEasy directly. Using a CDI interceptor could work, but the issue will still apply to clients created programmatically. @jamezp how about if we add something to RESTEasy that allows you to override the client builder? Consumers could then put some code around it, like it is done with the CDI Interceptor, but without requiring CDI. I'm more than happy to contribute that piece. @Olard I don't have a good workaround, except for catching the exceptions and closing the OpenTelemetry resources manually. |
@radcortez What did you have in mind? I'm not too sure ow we could allow overriding the public interface RestClientBuilderProvider {
/**
* A provider which can supply a {@link ClientBuilder} for create the
* {@linkplain jakarta.ws.rs.client.Client REST client}.
*
* @return the {@link ClientBuilder} to use for creating the REST client, cannot be {@code null}
*/
default ClientBuilder getClientBuilder() {
final ServiceLoader<RestClientBuilderProvider> loader = ServiceLoader.load(RestClientBuilderProvider.class);
if (loader.iterator().hasNext()) {
return loader.iterator().next().getClientBuilder();
}
return ClientBuilder.newBuilder();
}
} |
Yes, something similar, RESTEasy specific. That provider could be plugged into the |
The OpenTelemetryClientFilter causes a memory leak (and broken spans) by not handling failed requests (UnknownHostException, SocketTimeException, ...) as the filter method of the ClientResponseFilter interface is not called when there is no response.
The filter automatically registers itself with the JAX-RS client implementation via the jakarta.ws.rs.ext.Provider annotation and there is no way via the API to unregister a filter. Which means there is no way to prevent the leak unless you do something vendor specific.
It could be that the same thing happens for the OpenTelemetryServerFilter, but there it is mitigated by the fact that the exception mapper is called first which means you have a response again.
The text was updated successfully, but these errors were encountered: