-
Notifications
You must be signed in to change notification settings - Fork 869
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
Ratpack httpclient #4787
Ratpack httpclient #4787
Conversation
8534d3f
to
8f6032a
Compare
Thanks #4787 - I think bumping the version makes sense, 1.7 is pretty old and I haven't heard any demand for supporting older versions. Do you mind sending an initial PR with just the version bump to make these easier to review? |
13400cf
to
10261ac
Compare
Better to leave the renaming of the module for after the review 🙇 |
As I understand this introduces new library instrumentation for Ratpack and this requires v1.7. Do we actually need to upgrade our server instrumentation to 1.7 as well or we can leave it to continue to work with 1.4? |
We can create a new module to ratpack-1.7 and leave the ratpack-1.4 as it is, but I am not sure if there is any need to support ratpack-1.4 that is over 4 years old. Something I have been thinking is if we should be validating that the instrumentation works with newer version as well. What is the current approach for other library instrumentation? |
When you run tests with |
Sorry @anuraaga, I misunderstood you and undo the renaming of the module so the PR is easier to review. Do you think that makes sense to keep this PR to discuss the instrumentation approach of the Ratpack HttpClient and once it is reviewed, we can rename the module to @iNikem the instrumentation of the Ratpack HttpClient requires interceptors, therefore we need version |
I was hoping to do the version bump first, including directory rename, if there is consensus for it. It's a bit tricky discerning changes made for the bump vs ones for client instrumentation.
My vote is to bump for now - that being said I think we need a proper process for sunsetting instrumentation, which we haven't really done before. Perhaps we should target the next release for this change, first updating current instrumentation to log a warning that the version floor will change. Anyone have any thoughts? |
db4aceb
to
d013857
Compare
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.
Can you add http client library tests that extends AbstractRatpackHttpClientTest
? or at least tests that extends AbstractHttpClientTest
if the AbstractRatpackHttpClientTest
is not appropriate for library instrumentation? the base http client tests run a large array of standard tests to ensure that all of our http client instrumentations generate consistent telemetry.
d013857
to
5a6dd6f
Compare
I've been digging into the |
9e5f84a
to
2bd9cfb
Compare
Span span = Span.fromContext(otelCtx); | ||
String path = requestSpec.getUri().getPath(); | ||
span.updateName(path); | ||
// span.updateName("HTTP " + requestSpec.getMethod().getName()); // TODO use path instead of [HTTP method] |
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.
Based on the spec should be possible to leave name like /api/users/{user_id}
instead of HTTP GET
?
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.
it depends on if path is a template (e.g. /api/users/{user_id}
) or if it's a real url path (e.g. /api/users/5551234
)
thx @jsalinaspolo! i'll have a look at the failing tests tomorrow 👍 |
hey @jsalinaspolo, thanks for your patience. the problem in the tests appears to be that they are losing (local) context propagation across threads, somewhere between where the (synthetic) "parent" span is created and where the http client span is created. the reason the same tests probably work in the javaagent tests is because the javaagent instruments java executors in order to propagate context across threads I think your other library test |
@jsalinaspolo thanks for working through the tests! there's one more test issue, can you run this locally and check the failure?
sometimes failures against the latest dependency point to issues in the instrumentation, and sometimes issues with the tests themselves. if it's not clear how to make the instrumentation and tests work against both the base version and latest version, go ahead and post your findings, and we can help you sort it out (we have a variety of ways to deal with this common issue) |
750c511
to
c559781
Compare
import ratpack.http.client.RequestSpec; | ||
|
||
/** Entrypoint for tracing OkHttp clients. */ | ||
public final class RatpackHttpTracing { |
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.
Because Ratpack HTTP client can really only be used in a Ratpack server, do you think it makes sense to just keep one package and combine the entrypoints into one? Notably configureServerRegistry
can add the exec initializer too to keep things simpler.
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.
As far as we are happy to add the exec initializer at all times, I think might be easier to configure.
The only downside would be having too many classes in a package without structure while having client
server
and internal
might help to clarify.
Having different packages with a single RatpackTracing
have the problem that a few classes would need to be public
, which I understood was not ideal.
What do you think would be nicer? @anuraaga
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.
I made a refactor to have a flatter package structure following your suggestion @anuraaga
c412f55
to
ff0b013
Compare
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.
Just small point thanks!
} | ||
|
||
/** Returns instrumented instance of {@link HttpClient} with OpenTelemetry. */ | ||
public HttpClient instrumentedHttpClient(HttpClient httpClient) throws Exception { |
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.
Let's name it instrumentHttpClient
thx @jsalinaspolo! |
* Add Ratpack HttpClient instrumentation * Propagate trace through Ratpack HttpClient * Add test to verify trace propagation * Fix spotlessApply * Use HTTP method as name for ratpack http client * Add current Context to the execution * Fix HttpClient tests * Move Ratpack HttpClient tests to java package * Remove nullaway conventions from library * Add Context to ExecHarness executions * Remove ContextHolder from execution * Fix function test using other server stub * Fix lazy other app * Refactor ratpack client packages * Rename getter method
Proposal to support Ratpack HttpClient Instrumentation. The intention of the PR is to start a conversation about the proposal
🎉 Ratpack
1.7.0
supports HttpClient request/response/error interceptors, therefore ratpack version have been upgradedContextPropagation
, I have been unable to see the need but I am probably missing something.RatpackTracingBuilder
supportRatpackHttpTracing
or should be treated independently