zero88/scheduler.x

A scheduler based on plain Vertx promise/future/periodic/timer

Scheduler.x

A pluggable lightweight scheduler based on plain Vert.x core without any external libs for scheduling on time-based: cron and interval or on event-based.

Scheduler.x follows an event-driven architecture.

Please check out full documentation at web-docs

scheduler.x's Issues

Add TriggerEvaluator

Is your feature request related to a problem? Please describe.
Extract the logic to check the trigger is able to run or stop by condition to TriggerEvaluator
That makes easier to inject custom check into scheduler API from the application side.

Describe the solution you'd like

• The Trigger Evaluator must be chained-able
• The interface should be

interface TriggerEvaluator {

   Future<TriggerContext> shouldRun(...);

   Future<TriggerContext> shouldStop(...);
}

Scheduler thread management

Is your feature request related to a problem? Please describe.
In some cases:

• add a capability to pause/resume the scheduler
• when pause/cancel/shutdown the scheduler, how to manage the running execution
• Cancel the running execution in case of timeout by interrupt gracefully the thread that the execution is run on
• java21 virtual thread

Describe the solution you'd like
TBD

Optimize CronExpression

EventTrigger should be able to persist

Is your feature request related to a problem? Please describe.
To persist the EventTrigger into database/local storage. the EventTriggerPredicate should be serializable/de-serializable

Describe the solution you'd like

• Use JSON schema validation as one type of EventTriggerPredicate
• Serialize/de-serialize java object directly

Rename artifact

• vertx-scheduler => schedulerx

Trigger representation

Is your feature request related to a problem? Please describe.

Describes CronTrigger/IntervalTrigger/EventTrigger as human-readable text

Describe the solution you'd like

This ticket aims to create SPI to describe the trigger to:

• SPI interface
• simple representation
• #71

Upgrade gradle

• Gradle 7.6.2
• Use cloud.playio.gradle plugin
• Use template workflow from https://github.com/zero88/java-gradle-template

Add capability to mock the timeline in scheduling

Is your feature request related to a problem? Please describe.
In order to test the schedule on some future/past timeline, need to override system time and make it mockable.
It should be compatible with Vert.x timer and periodic

Describe the solution you'd like

• #100
• ...

Trigger Rule with Calendar

Is your feature request related to a problem? Please describe.

• For scheduling stuff in the working days, weekends or holidays, etc
• Calendar is configurable depending on the country calendar such as Hindu calendar, Lunar calendar, etc..

Describe the solution you'd like

Improve SchedulingMonitor

Is your feature request related to a problem? Please describe.

• Scheduling Monitor is registered from the client side, there is no guarantee that it is a non-blocking code, and fast enough to run in the default Vertx event loop thread.
• The monitor should act as a subscriber on the "execution result" topic => should allow more than one monitor in the scheduler

Describe the solution you'd like

• Scheduling monitor is run in the worker executor
• Create a delegate monitor that can register multiple scheduling monitors
• Create an internal monitor to ensure no unexpected exceptions when distributing the execution result by the registered scheduling monitor

Prevent to start the executor many times

Describe the bug
A clear and concise description of what the bug is.

Version
Library version

To Reproduce
Steps to reproduce the behavior

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

Make contract between Task and TaskExecutionState + TaskResult

** Is your feature request related to a problem? Please describe.
Enforce typing between JobData and Task
That makes coding life easier in the compile time to avoid cast data

** Describe the solution you'd like

interface TaskExecutionContext<OUTPUT> {
}
interface Task<INPUT, OUTPUT>{
    void execute(@NotNull JobData<INPUT> jobData, @NotNull TaskExecutionContext<OUTPUT>  executionContext);
}

Remove lombok

• To build doc with java17

Cron Trigger still run one more round after invoking force stop in current round

Describe the bug
A clear and concise description of what the bug is.

Version
Library version

To Reproduce
Steps to reproduce the behavior

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Additional context
Add any other context about the problem here.

Add capability in the scheduler that allows the user to `pause` and `resume`

Preview schedule

Is your feature request related to a problem? Please describe.
Add preview for each kind of trigger

Describe the solution you'd like

interface Trigger {
    List<OffsetDateTime> preview();
    List<OffsetDateTime> preview(PreviewParameter parameter);
}

Trigger should be able to control its executor to start or stop

Describe the solution you'd like
Add these methods in Trigger

• boolean shouldExecute(@NotNull Instant triggerAt)
• boolean shouldStop(long round)

Improve Trigger

Describe the solution you'd like

• Improve IntervalTrigger
  • Use java8 Duration for initialDelay and interval configuration
  • Back-ward compatible in Builder and JSON deserialization
• Improve Trigger
  • Mark *TriggerBuilder is @Internal
  • Default preview using rule from Trigger

Add advance trigger rule

Is your feature request related to a problem? Please describe.

• Until datetime
• Include/Exclude datetime
• Start after datetime/Stop after datetime

Describe the solution you'd like
A clear and concise description of what you want to happen.

Add external id in JobData

- [ ] Rename to JobConfig => no need

• Add external id from an external system to identify a task
• Propagate the external id to the TaskResult, then the developer can access the task id when doing TaskExecutorMonitor

Add AsyncJob

Is your feature request related to a problem? Please describe.
Support out of the box AsyncJob

Describe the solution you'd like
Make new interface

interface Job<INPUT, OUTPUT> {
    void execute(@NotNull JobData<INPUT> jobData, @NotNull ExecutionContext<OUTPUT> executionContext);
}

interface AsyncJob<INPUT, OUTPUT> extends Job<INPUT, OUTPUT> {
    Future<OUTPUT> asyncExecute(@NotNull JobData<INPUT> jobData, @NotNull ExecutionContext<OUTPUT> executionContext);
}

Add Timeout configuration in execution

Is your feature request related to a problem? Please describe.
The Vert.x WorkerExecutor has maxWorkerExecuteTime config.
However, within this config, the Vertx worker cannot be stopped and/or interrupted when exceeding max execution time. In this situation, the Vert.x BlockedThreadChecker with the default handler only does a warning log.

Need a mechanism to stop the execution when it reaches a specific timeout.

Describe the solution you'd like

• Add a timeout config and pass into Scheduler
  • Timeout to control how long the trigger is runnable evaluation operation. Defaults is VertxOptions#DEFAULT_MAX_EVENT_LOOP_EXECUTE_TIME
  • Timeout to control how long the job execution. Defaults is VertxOptions#DEFAULT_MAX_WORKER_EXECUTE_TIME
• Notify Timeout exception in Monitor
• If the execution timeout differs to VertxOptions#DEFAULT_MAX_WORKER_EXECUTE_TIME, auto create WorkerExecutor with maxWorkerExecuteTime == given execution timeout to re-use logging feature from BlockedThreadChecker

Add begin time in TriggerRule

Is your feature request related to a problem? Please describe.
Add beginTime in TriggerRule to indicate when the trigger’s schedule first comes into effect.

• if the value is null or in the past, the current time (immediately) is assumed
• if the value is future, the trigger will be delayed to schedule

Describe the solution you'd like

Upgrade vertx

• Upgrade vertx version
• Use internal logging
• Add rxify/mutiny version. Required #45 done

Change `the evaluation on the trigger before run` to async operation

Is your feature request related to a problem? Please describe.
The evaluation on the trigger before run operation can be an expensive process, that is a blocking operation in some cases:

• EventTrigger predicate does validation
• To integrate an external system to avoid race conditions that run the same trigger+task among compute engine (cloud native)

Describe the solution you'd like
Change this operation to run on a dedicated thread pool or using Vertx.executeBlocking

Add TriggerContext condition state `executed`

Is your feature request related to a problem? Please describe.
...

Describe the solution you'd like
...

Add leeway time for trigger rule

Describe the solution you'd like
Allow a little leeway time in the trigger rule.
Add a configuration that can be attached into the time validation of

• until
• timeframe

Enrich the trigger representation

inject with an external library and support multiple languages later. E.g: https://github.com/bradymholt/cron-expression-descriptor

Rename `Task` to `Job`

Is your feature request related to a problem? Please describe.
...

Describe the solution you'd like
Rename Task and relevant interfaces/classes to Job

• Task -> Job
• TaskExecutor -> JobExecutor
• TaskExecutorProperties -> JobExecutorConfig

Integrate tracer

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like
A clear and concise description of what you want to happen.

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• fix(deps): update dependency ch.qos.logback:logback-classic to v1.5.6
• fix(deps): update jacksonlibs.version.jackson to v2.17.1 (com.fasterxml.jackson.datatype:jackson-datatype-jsr310, com.fasterxml.jackson.core:jackson-databind, com.fasterxml.jackson.core:jackson-annotations)
• fix(deps): update dependency io.smallrye.reactive:smallrye-mutiny-vertx-core to v2.30.1
• fix(deps): update dependency io.smallrye.reactive:smallrye-mutiny-vertx-core to v3
• Click on this checkbox to rebase all open PRs at once

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

• chore(deps): update dependency gradle to v8

Detected dependencies

github-actions

.github/workflows/ci.yml

• softprops/action-gh-release v2

gradle

buildSrc/src/main/kotlin/Dependencies.kt

• org.jetbrains:annotations 24.1.0
• ch.qos.logback:logback-classic 1.5.3
• com.fasterxml.jackson.core:jackson-annotations 2.17.0
• com.fasterxml.jackson.core:jackson-databind 2.17.0
• com.fasterxml.jackson.datatype:jackson-datatype-jsr310 2.17.0
• org.junit.jupiter:junit-jupiter-api 5.10.2
• org.junit.jupiter:junit-jupiter-engine 5.10.2
• org.junit.vintage:junit-vintage-engine 5.10.2
• org.junit.jupiter:junit-jupiter-params 5.10.2
• org.junit-pioneer:junit-pioneer 2.2.0
• io.smallrye.reactive:smallrye-mutiny-vertx-core 2.27.0

gradle.properties

settings.gradle.kts

build.gradle.kts

buildSrc/build.gradle.kts

core/build.gradle.kts

docs/build.gradle.kts

event-trigger-jsonschema/build.gradle.kts

gradle-wrapper

gradle/wrapper/gradle-wrapper.properties

• gradle 7.6.4

---

• Check this box to trigger a request for Renovate to run again on this repository

Make contract between Task and JobData

Is your feature request related to a problem? Please describe.
Enforce typing between JobData and Task
That makes coding life easier in the compile time to avoid cast data

Describe the solution you'd like

interface JobData<T> {
    <T> T get();
}
interface Task<T>{
    void execute(@NotNull JobData<T> jobData, @NotNull TaskExecutionContext executionContext);
}

Add event trigger

Is your feature request related to a problem? Please describe.
Declare an event trigger configuration and evaluate if this trigger can run in an incoming event

Describe the solution you'd like

• Subscribe to a specific event-bus address
• Add a predicate to decide an incoming event should be able to trigger
• Attach event data into the execution context that let task can understand the incoming event context

Cron task with repeating until a given time / date

Class naming convention

Rename interfaces and its sub-interface/sub-classes

• TriggerTaskExecutor -> Scheduler
• TaskExecutionContext -> ExecutionContext
• TaskResult -> ExecutionResult
• TaskExecutorState -> SchedulerState
• TaskExecutorMonitor -> SchedulingMonitor

NLP from Trigger Descriptor to build the Trigger

Is your feature request related to a problem? Please describe.

Describe the solution you'd like

• Cron Builder
• Create model

Wrap `Instant.now()` to interface and make it injectable into `Scheduler`

Add TriggerCondition

Is your feature request related to a problem? Please describe.
It is ideal to add TriggerCondition to describe more insights of Trigger when it is skipped, stopped, unable to schedule

Execution Rate-limit policy

Is your feature request related to a problem? Please describe.

• In the case of EventTrigger, the event can be fired in massive in a short time
• In the case of Timing Trigger, the execution can be longer than the trigger period

Currently, schedulerx only allows running one job of a specified trigger in one moment. That is a limitation.
It is ideal to add a throttle mechanism to restrict the incoming event message for EventTrigger or in general, control the number of execution rounds of one trigger that can be run in parallel in a certain period.

Describe the solution you'd like
Provide the execution rate-limit policy interface, that

• Supports local memory counter
• Supports remote counter, such as the scheduler app is deployed on multiple instances in the cluster

Scheduler Manager

Is your feature request related to a problem? Please describe.
The scheduler manager is in charge of

• Construct a list of schedulers by reading triggers and tasks from backend storage (json/database).
• start multiple triggers in parallel
• Provides a load-balancer for the schedulers, allowing them to run as a cloud-native solution within the cluster. That means: If trigger A has already been run on container C1 at a specific time, it will be skipped on container C2.

Describe the solution you'd like

Change Timeframe#from to minimum allowed value (inclusive)

Timeframe

• from inclusive value
• to exclusive value

Result: from <= value < to, value in [from, to)