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

Provide a new ApplicationNotRunning predicate for @Scheduled #24605

Merged

Conversation

knutwannheden
Copy link
Contributor

The @Scheduled annotation's skipExecutionIf attribute can be used to skip individual executions in a schedule. Currently, Quarkus only provides the Never implementation, which is also the default (never skips an execution).

Since the scheduler is initialized very early (priority PLATFORM_BEFORE) it can happen that executions get scheduled before the application has been fully started. An application can solve this by itself waiting to get notified with the StartupEvent or it can now use this new predicate: @Scheduled(..., skipExecutionIf = ApplicationNotRunning.class).

Copy link
Contributor

@mkouba mkouba left a comment

Choose a reason for hiding this comment

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

Looks good! I've added two minor comments.

The `@Scheduled` annotation's `skipExecutionIf` attribute can be used to skip individual executions in a schedule. Currently, Quarkus only provides the `Never` implementation, which is also the default (never skips an execution).

Since the scheduler is initialized very early (priority `PLATFORM_BEFORE`) it can happen that executions get scheduled before the application has been fully started. An application can solve this by itself waiting to get notified with the `StartupEvent` or it can now use this new predicate: `@Scheduled(..., skipExecutionIf = ApplicationNotRunning.class)`.
@knutwannheden knutwannheden force-pushed the applicationnotrunning-skippredicate branch from 8c694ed to 785e88a Compare April 1, 2022 14:02
@josephearl
Copy link

As a user I wonder if this should become the default at some point (I was unaware the scheduler could start tasks before the application is started, and I wonder how useful that is or why I might want that)

@mkouba
Copy link
Contributor

mkouba commented Apr 5, 2022

As a user I wonder if this should become the default at some point (I was unaware the scheduler could start tasks before the application is started, and I wonder how useful that is or why I might want that)

Well, it depends on how you define "application is started". The only "hard requirement" for scheduled methods is that the CDI container must be running. And in many cases, it's OK to execute a scheduled method before the StartupEvent is fired before the StartupEvent is delivered to observers with higher priority values (2000 by default) .

@mkouba mkouba merged commit 85e1f13 into quarkusio:main Apr 5, 2022
@quarkus-bot quarkus-bot bot added this to the 2.9 - main milestone Apr 5, 2022
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.

3 participants