-
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
Executes scheduled methods on duplicated contexts #28255
Conversation
- Remove the executor from the ScheduledContext as it was confusing and can only be used for blocking methods - Create a duplicated context for both blocking and non-blocking invocation - Blocking invocation use executeBlocking, which uses the same thread pool as the previous executor - It is not possible to create the duplicated context in the thread factory (an idea discussed with Bruno and Martin because it creates a chicken-and-egg problem) - Simplify the dev console @scheduled support to use the same strategy - no need to play with the classloader anymore as there is no more in-thread direct invocation and the Vert.x thread that will be used has the right TCCL configured
Should this be backported? |
This comment has been minimized.
This comment has been minimized.
@gsmet no, I would consider that as a new feature. |
Did you double-check?
Note that this would be a breaking change because of a different thread used to execute a scheduled method. We should also ask @machi1990 for opinion - there might be some quartz features that rely on execution in the built-in thread pool. |
@mkouba yes, I double check on which thread pool things were and are executed: it's the same. |
@holly-cummins JDK 17 MacOS M1failure ^ |
…ntext. This is the follow-up of quarkusio#28255. When running the scheduled method, the lack of duplicated context can lead to contextual data loss (loss only, no leak). This commit makes sure that the method runs with a duplicated context. However, this is a breaking change for users expecting the method to run on a Quartz thread.
…ntext. This is the follow-up of quarkusio#28255. When running the scheduled method, the lack of duplicated context can lead to contextual data loss (loss only, no leak). This commit makes sure that the method runs with a duplicated context. However, this is a breaking change for users expecting the method to run on a Quartz thread.
…ntext. This is the follow-up of quarkusio#28255. When running the scheduled method, the lack of duplicated context can lead to contextual data loss (loss only, no leak). This commit makes sure that the method runs with a duplicated context. However, this is a breaking change for users expecting the method to run on a Quartz thread.
…ntext. This is the follow-up of quarkusio#28255. When running the scheduled method, the lack of duplicated context can lead to contextual data loss (loss only, no leak). This commit makes sure that the method runs with a duplicated context. However, this is a breaking change for users expecting the method to run on a Quartz thread.
…ntext. This is the follow-up of quarkusio#28255. When running the scheduled method, the lack of duplicated context can lead to contextual data loss (loss only, no leak). This commit makes sure that the method runs with a duplicated context. However, this is a breaking change for users expecting the method to run on a Quartz thread.
…ntext. This is the follow-up of quarkusio#28255. When running the scheduled method, the lack of duplicated context can lead to contextual data loss (loss only, no leak). This commit makes sure that the method runs with a duplicated context. However, this is a breaking change for users expecting the method to run on a Quartz thread.
…ntext. This is the follow-up of quarkusio#28255. When running the scheduled method, the lack of duplicated context can lead to contextual data loss (loss only, no leak). This commit makes sure that the method runs with a duplicated context. However, this is a breaking change for users expecting the method to run on a Quartz thread.
…ntext. This is the follow-up of quarkusio#28255. When running the scheduled method, the lack of duplicated context can lead to contextual data loss (loss only, no leak). This commit makes sure that the method runs with a duplicated context. However, this is a breaking change for users expecting the method to run on a Quartz thread.
Fix #28017
A follow-up for Quartz will be implemented later.