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

Remove JAXRS HttpClient instrumentations #5430

Merged
merged 1 commit into from
Mar 1, 2022
Merged

Remove JAXRS HttpClient instrumentations #5430

merged 1 commit into from
Mar 1, 2022

Conversation

trask
Copy link
Member

@trask trask commented Feb 23, 2022

The Jersey, CXF and RESTEasy http client instrumentations are producing duplicate CLIENT spans currently, because they use HttpURLConnection by default (which looks pluggable at least in some cases).

(btw another reason for #5261 (comment))

The standard solution of course is to make the client spans created by these instrumentations "active" before they delegate to underlying http client library.

This is surprisingly difficult because of the layer at which this instrumentation is written.

The instrumentation is written as a JAX-RS ClientRequestFilter and ClientResponseFilter, I suspect in order to get access to the underlying HTTP url and response code, which aren't readily available at the JAXRS layer.

But this makes things hard already because the ClientResponseFilter doesn't get called for exceptions (and thus the various and slightly odd JAXRS implementation-specific instrumentations).

And it makes it hard to propagate context because it's not clear to me that these two filters will be called in the same thread (e.g. JAXRS supports async http client calls returning Future).

But then I am really wondering what's the value of these JAXRS client spans over the underlying http client spans.

If the JAXRS client were captured at the top level where the application code interacted with it, I would see value. But as it is, the spans are captured in between where the application code interacts with it and the underlying http client, which seems to have very limited value.

Maybe we should capture these JAXRS spans where the application code interacts with it (e.g. javax.ws.rs.client.AsyncInvoker) and capture them as INTERNAL spans with their own convention. I think this could parallel the hibernate instrumentation, since they are both "object" interfaces on top of underlying http/sql.

But I'm not personally convinced that these INTERNAL spans would have a lot of value (similar to my opinion about the hibernate INTERNAL spans), so I'm proposing we just delete this instrumentation (but keep the tests, which still pass!) and wait for more user feedback to justify value in capturing INTERNAL spans.

EDIT on third thought, I'm sort of not sure what the point of keeping only the tests is, although they did uncover a bug in the HttpURLConnection instrumentation, and they are already written....

@trask trask changed the title Remove JAXRS HttpClient instrumentation Remove JAXRS HttpClient instrumentations Feb 23, 2022
@trask trask marked this pull request as ready for review February 23, 2022 02:01
@trask trask requested a review from a team February 23, 2022 02:01
@trask
Copy link
Member Author

trask commented Feb 28, 2022

@laurit curious your thoughts on this

Copy link
Contributor

@laurit laurit left a comment

Choose a reason for hiding this comment

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

@trask I agree with your analysis. The duplicate client span is definitely a bug. I wasn't able to find additional value over what http-url-connection or apache-httpclient instrumentation provides.

@trask trask merged commit c06d70d into open-telemetry:main Mar 1, 2022
@trask trask deleted the remove-jaxrs-client-instrumentation branch March 1, 2022 06:47
RashmiRam pushed a commit to RashmiRam/opentelemetry-auto-instr-java that referenced this pull request May 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants