-
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
Make copying of Vertx context data conditional #22766
Conversation
/cc @radcortez |
This workflow status is outdated as a new workflow run has been triggered. Failing Jobs - Building 71a7f81
Failures⚙️ Initial JDK 11 Build #- Failing: extensions/opentelemetry/opentelemetry/deployment
! Skipped: docs extensions/opentelemetry/opentelemetry-exporter-jaeger/deployment extensions/opentelemetry/opentelemetry-exporter-otlp/deployment and 4 more 📦 extensions/opentelemetry/opentelemetry/deployment✖ |
71a7f81
to
d5bc289
Compare
...ent/src/main/java/io/quarkus/resteasy/reactive/server/spi/CopyVertxContextDataBuildItem.java
Outdated
Show resolved
Hide resolved
Note that this shouldn't be seen as a fix for the potential regression performance and we still need to check it. Because, if we end up doing this a lot, we will have users with an app that is working fine and that has degraded performance when adding telemetry. |
Still need to check what? I am not following |
The penalty of what @radcortez introduced and if it should be done this way. I don't want us to have a very optimized thing that falls apart when you add telemetry :). BTW, I'm not against this PR, just that it doesn't prevent us from making sure the penalty is not too big. |
Sure, checking further should be a next step, but it's entirely possible that we won't be able to avoid this type of copying for the case of telemetry. |
Also, it's a given that any sort of telemetry will add some overhead. What we don't want is to pay that price if no telemetry is needed |
We can probably make it even smarter, by only copying the context if the trace is sampled. Anyway, it would be interesting to measure the performance hit, not only for this case but for telemetry overall. Let me add that to my TODO list :) |
It concerns me that such a "condition" might be yet-another source of things that breaks or magically get fixed when an extension is added [removed]. We need to be careful in making things nicely composeable for Quarkus to be a viable platform for non-trivial applications; maybe best to explore such options only if we see there is a performance problem? Also wondering: does telemetry need the whole map or is it needing some specific element? If we could "copy" only what it needs, at least it wouldn't have unexpected side-effects. In which case, perhaps what we need is a similar BuildItem, but which allows registering what exactly needs to be copied. |
This workflow status is outdated as a new workflow run has been triggered. Failing Jobs - Building d5bc289
Full information is available in the Build summary check run. Failures⚙️ Gradle Tests - JDK 11 Windows #- Failing: integration-tests/gradle
📦 integration-tests/gradle✖
⚙️ JVM Tests - JDK 11 #- Failing: integration-tests/opentelemetry-vertx
📦 integration-tests/opentelemetry-vertx✖
⚙️ JVM Tests - JDK 11 Windows #- Failing: integration-tests/opentelemetry-vertx
📦 integration-tests/opentelemetry-vertx✖
⚙️ JVM Tests - JDK 17 #- Failing: integration-tests/opentelemetry-vertx
📦 integration-tests/opentelemetry-vertx✖
⚙️ MicroProfile TCKs Tests #- Failing: tcks/microprofile-fault-tolerance
📦 tcks/microprofile-fault-tolerance✖
|
Yes, the entire map is not required. We can just copy the specific element that carries the OTel context. When I wrote the fix, I thought about it, but I didn't want to be specific about OTel, so a build item to copy specific things sounds better. |
d5bc289
to
0189dc3
Compare
I updated the PR to use the named approach |
3c06f34
to
71eebdd
Compare
This workflow status is outdated as a new workflow run has been triggered. Failing Jobs - Building 71eebdd
Failures⚙️ Initial JDK 11 Build #- Failing: extensions/opentelemetry/opentelemetry/deployment
! Skipped: docs extensions/opentelemetry/opentelemetry-exporter-jaeger/deployment extensions/opentelemetry/opentelemetry-exporter-otlp/deployment and 4 more 📦 extensions/opentelemetry/opentelemetry/deployment✖ |
In order to avoid negatively affecting RESTEasy Reactive performance just to serve very specific use cases, we introduce a way to conditionally control when the current Vertx request context data needs to be copied into the connection context Follow up off: quarkusio#22671
71eebdd
to
8735ad1
Compare
In order to avoid negatively affecting RESTEasy Reactive performance
just to serve very specific use cases, we introduce a way to
conditionally control when the current Vertx request context data needs
to be copied into the connection context
Follow up of: #22671