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

Fix Mutiny schedulers context propagation bug #26242

Merged
merged 1 commit into from Jun 23, 2022

Conversation

jponge
Copy link
Member

@jponge jponge commented Jun 20, 2022

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

@quarkus-bot quarkus-bot bot added area/dependencies Pull requests that update a dependency file area/mutiny area/smallrye labels Jun 20, 2022
@quarkus-bot
Copy link

quarkus-bot bot commented Jun 20, 2022

Thanks for your pull request!

The title of your pull request does not follow our editorial rules. Could you have a look?

  • title should not contain an issue number (use Fix #1234 in the description instead)

This message is automatically generated by a bot.

@jponge jponge changed the title Fix for #25818 and upgrade to Mutiny 1.6.0 Fix #25818 and upgrade to Mutiny 1.6.0 Jun 20, 2022
@jponge jponge changed the title Fix #25818 and upgrade to Mutiny 1.6.0 Fix Mutiny schedulers context propagation bug and upgrade to Mutiny 1.6.0 Jun 20, 2022
@jponge jponge requested a review from cescoffier June 20, 2022 15:48
@jponge jponge requested a review from geoand June 20, 2022 16:22
Copy link
Contributor

@luneo7 luneo7 left a 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);
Copy link
Contributor

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.

Copy link
Member Author

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.

Copy link
Member Author

Choose a reason for hiding this comment

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

Wrapping in an Optional<...>

Copy link
Contributor

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

Copy link
Contributor

Choose a reason for hiding this comment

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

Making it runtimeInit accept optional:

image

Creating the right MutinyScheduler if context handler is not null:
image

Copy link
Contributor

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

Copy link
Member Author

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 👍

Copy link
Member Author

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

@jponge jponge marked this pull request as draft June 20, 2022 17:25
@quarkus-bot

This comment has been minimized.

jponge added a commit to jponge/quarkus that referenced this pull request Jun 20, 2022
Adapted from the draft code from @luneo7 in the discussions of
- quarkusio#26242
- quarkusio#25818
@jponge
Copy link
Member Author

jponge commented Jun 20, 2022

a06b438 is an adaptation of @luneo7 code, with added tests.

With these changes, all executor methods (scheduleXYZ, submit, execute) should propagate the Vert.x context, so it indeed goes beyond the initial fix. Thanks @luneo7 for insisting on these points.

@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.

@geoand
Copy link
Contributor

geoand commented Jun 21, 2022

I'll leave this one to you and @cescoffier :)

@@ -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) {
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Contributor

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.

@jponge jponge requested a review from cescoffier June 21, 2022 07:44
jponge added a commit to jponge/quarkus that referenced this pull request Jun 21, 2022
…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
@jponge jponge marked this pull request as ready for review June 21, 2022 13:48
jponge added a commit to jponge/quarkus that referenced this pull request Jun 21, 2022
…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
@jponge
Copy link
Member Author

jponge commented Jun 21, 2022

Reworked as a single commit, ready for another review @cescoffier

@gsmet
Copy link
Member

gsmet commented Jun 21, 2022

Wondering if we should backport it to 2.10.1.Final as it looks rather annoying? Please add the triage/backport? label if I'm not mistaken.

@jponge
Copy link
Member Author

jponge commented Jun 21, 2022

This is for rather advanced use cases, but yes it's worth a potential backport.

@jponge jponge changed the title Fix Mutiny schedulers context propagation bug and upgrade to Mutiny 1.6.0 Fix Mutiny schedulers context propagation bug Jun 21, 2022
@quarkus-bot

This comment has been minimized.

jponge added a commit to jponge/quarkus that referenced this pull request Jun 22, 2022
…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
@jponge
Copy link
Member Author

jponge commented Jun 22, 2022

(rebased)

@jponge
Copy link
Member Author

jponge commented Jun 22, 2022

CI is green, waiting for @cescoffier to do another review

@jponge
Copy link
Member Author

jponge commented Jun 22, 2022

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
@jponge
Copy link
Member Author

jponge commented Jun 22, 2022

Fixed

@cescoffier cescoffier merged commit d28eb6e into quarkusio:main Jun 23, 2022
@quarkus-bot quarkus-bot bot added this to the 2.11 - main milestone Jun 23, 2022
@gsmet gsmet modified the milestones: 2.11 - main, 2.10.1.Final Jun 28, 2022
gsmet pushed a commit to gsmet/quarkus that referenced this pull request Jun 28, 2022
…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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Vert.x Context doesn't get propagated when using Infrastructure.getDefaultWorkerPool()
5 participants