-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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 vertx otel sdk reload in devmode #28792
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
c72884c
to
dfd650b
Compare
dfd650b
to
1b35191
Compare
This comment has been minimized.
This comment has been minimized.
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 think we need to avoid the check on each tracer method because this would only be useful for DEV mode, but we still are doing the check for runtime with no gain.
My recommendation is to produce a CDI Bean of VertxTracer
, so we have updated Instrumenters with the correct OpenTelemetry instance. Then in the OpenTelemetryVertxTracingFactory
, we just have a delegate to the CDI VertTracer
and keep a reference to the one we pass to the factory, so we can update it by replacing the new CDI Bean on reload.
To make the span also works on the reload request, I think we can recreate the start of the span on VertxHttpHotReplacementSetup
before the root handler dispatches the current request. We have the instance of VertxTracer
, so we can call the receiveRequest
method, and we should have everything available for it.
The tricky part is that the current request holds the state of the Trace object (created initially by the request that triggered the reload). In this case, we would need to access the request internal state directly to replace the Trace object. There are no API's for that, but I think that some bytecode transformations for this particular case (and only for DEV mode) are not going to hurt.
...kus/opentelemetry/runtime/tracing/intrumentation/vertx/OpenTelemetryVertxTracingFactory.java
Show resolved
Hide resolved
.../opentelemetry/runtime/tracing/intrumentation/vertx/wrapper/DevModeOpenTelemetryWrapper.java
Outdated
Show resolved
Hide resolved
...quarkus/opentelemetry/runtime/tracing/intrumentation/vertx/wrapper/OpenTelemetryWrapper.java
Outdated
Show resolved
Hide resolved
The current check is basically just a volatile read. The CDI approach you are talking about will almost certainly be way more expensive per request. |
I would prefer to avoid anything CDI related, if possible and keep the current strategy... Maybe simplify the detection to setup instrumenters into helper method. |
But you can completely avoid that check. And it is not only about the check. Since you need to add it to every tracing method, we must remember to always add that check to all implementations moving forward. Also, I believe instruments shouldn't have to deal with code that is only relevant for Dev mode. The issue is that since Vert.x is always the same instance from restart to restart, the As for CDI, the issue is that we should remove calls to |
1b35191
to
71c6f7d
Compare
@stuartwdouglas , in the end, @radcortez proposal about creating delegates on the the Tracer Factory makes more sense because it will not require future changes in the instrumenters themselves. |
@gsmet any prediction on when this can be merged? |
I'll merge it. |
Part of #26444
Currently OTel will not live reload, working only on first start.
This PR includes:
Caveat: