-
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 Mutiny schedulers context propagation bug #26242
Conversation
Thanks for your pull request! The title of your pull request does not follow our editorial rules. Could you have a look?
|
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.
What about the schedule methods? Shouldn't they also propagate Vert.x context?
|
||
@Override | ||
public ScheduledFuture<?> schedule(Runnable command, long delay, TimeUnit unit) { | ||
return mutinyScheduler.schedule(command, delay, unit); |
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.
If we schedule something, inside a route handler the Vert.x context won't be propagated, just when execute
is called, that would mean schedule it to run right away... If someone use the Infrastructure.getDefaultWorkerPool
and call any of the schedule methods it won't propagate the vert.x context.
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'm trying a variation of your code (we won't add another parameter to Infrastructure
in Mutiny) but I get an error testing the Mutiny extension:
Errors:
[ERROR] MutinyTest » Runtime java.lang.RuntimeException: io.quarkus.builder.ChainBuildException: No producers for required item class io.quarkus.deployment.builditem.ContextHandlerBuildItem
Other than that I have added test cases calling submit
and schedule
, context does propagate with your changes to the Vert.x extension.
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.
Wrapping in an Optional<...>
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.
Yup, in the mutiny processor the runtimeInit needs to take an Optional<ContextHandlerBuildItem> contextHandlerBuildItem
and need to update the code when there is no context handler
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.
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.
Pushed it to my branch, if you are basing on something there: main...luneo7:mutiny-executors-simple
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 already have something like this locally 👍
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 just let a null
handler being forwarded, and just call Runnable::run()
when null
in CRSF
This comment has been minimized.
This comment has been minimized.
Adapted from the draft code from @luneo7 in the discussions of - quarkusio#26242 - quarkusio#25818
a06b438 is an adaptation of @luneo7 code, with added tests. With these changes, all executor methods ( @geoand @cescoffier I'm keeping this PR as a draft right now so we can discuss, I'm not a specialist of the Vert.x extension and there's also a slight change here. I'll eventually squash commits, etc. |
extensions/mutiny/runtime/src/main/java/io/quarkus/mutiny/runtime/MutinyInfrastructure.java
Outdated
Show resolved
Hide resolved
...utiny/runtime/src/main/java/io/quarkus/mutiny/runtime/ContextualRunnableScheduledFuture.java
Outdated
Show resolved
Hide resolved
I'll leave this one to you and @cescoffier :) |
...utiny/runtime/src/main/java/io/quarkus/mutiny/runtime/ContextualRunnableScheduledFuture.java
Outdated
Show resolved
Hide resolved
extensions/mutiny/runtime/src/main/java/io/quarkus/mutiny/runtime/MutinyInfrastructure.java
Outdated
Show resolved
Hide resolved
@@ -546,14 +546,15 @@ public Object captureContext() { | |||
|
|||
@Override | |||
public void runWith(Runnable task, Object context) { | |||
if (context != null) { | |||
ContextInternal currentContext = (ContextInternal) Vertx.currentContext(); | |||
if (context != null && context != currentContext) { |
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.
And now the philosophical question: should we distinguish root context and duplicated context?
I do not believe so, but I think we should consider the question.
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.
Duplicated contexts do not share the context-local data, so I would say we are running with a different context.
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.
Those context are mostly duplicated contexts. When you duplicate a root context, their local data will also by propagated to the duplicate context, the only thing is that changing this local data won't change the root local data.
When I added this check ’if not null and if different from current’ was just a safe guard if trying to run the context handler twice in the same context, so we don't dispatch the vertx context multiple times. Since the executor will span a thread that is not a vertx thread, when you try to get the current vertx context it will always be null, unless the context handler was run multiple times in that thread.
Don't think that we need to distinguish root and duplicated contexts.
…hedulers Fixes quarkusio#25818 This is part of a coordinated fix across Quarkus and Mutiny where scheduler wrapping would cause Vert.x context propagation not to be done. Some changes have been adapted from the draft code from @luneo7 in the discussions of: - quarkusio#26242 - quarkusio#25818 See the matching changes in Mutiny: smallrye/smallrye-mutiny#955
…hedulers Fixes quarkusio#25818 This is part of a coordinated fix across Quarkus and Mutiny where scheduler wrapping would cause Vert.x context propagation not to be done. Some changes have been adapted from the draft code from @luneo7 in the discussions of: - quarkusio#26242 - quarkusio#25818 See the matching changes in Mutiny: smallrye/smallrye-mutiny#955
Reworked as a single commit, ready for another review @cescoffier |
Wondering if we should backport it to 2.10.1.Final as it looks rather annoying? Please add the |
This is for rather advanced use cases, but yes it's worth a potential backport. |
This comment has been minimized.
This comment has been minimized.
…hedulers Fixes quarkusio#25818 This is part of a coordinated fix across Quarkus and Mutiny where scheduler wrapping would cause Vert.x context propagation not to be done. Some changes have been adapted from the draft code from @luneo7 in the discussions of: - quarkusio#26242 - quarkusio#25818 See the matching changes in Mutiny: smallrye/smallrye-mutiny#955
(rebased) |
CI is green, waiting for @cescoffier to do another review |
Ah... conflicts, great |
…hedulers Fixes quarkusio#25818 This is part of a coordinated fix across Quarkus and Mutiny where scheduler wrapping would cause Vert.x context propagation not to be done. Some changes have been adapted from the draft code from @luneo7 in the discussions of: - quarkusio#26242 - quarkusio#25818 See the matching changes in Mutiny: smallrye/smallrye-mutiny#955
Fixed |
…hedulers Fixes quarkusio#25818 This is part of a coordinated fix across Quarkus and Mutiny where scheduler wrapping would cause Vert.x context propagation not to be done. Some changes have been adapted from the draft code from @luneo7 in the discussions of: - quarkusio#26242 - quarkusio#25818 See the matching changes in Mutiny: smallrye/smallrye-mutiny#955 (cherry picked from commit 059b7b7)
This is part of a coordinated fix across Quarkus and Mutiny where scheduler wrapping would cause Vert.x context propagation not to be done.
See smallrye/smallrye-mutiny#955
Fixes #25818