These are the key components that are relevant for scheduling purposes.
ScheduledJob (and implicitly
ScheduledJobDetail) entity instances by handling basic CRUD operations.
Responsible for querying the datastore and building/scheduling Quartz jobs for each
Once the Quartz jobs are scheduled in its
JobStore, Quartz assumes responsibility of firing them at the appropriate time.
This is the default implementation of a Quartz job which
SchedulerService will build for each
Quartz will invoke the job’s
execute() method at the scheduled time.
execute() implementation is responsible for updating the
ScheduledJob in the datastore to mark it as executed, and then invoking
NotificationHandler to emit the associated triggered job message to the message channel.
These are the key components that are relevant for making the scheduled job service operate as a "singleton" (or "active-passive") cluster.
This is an Apache Camel concept that is responsible for managing cluster resources such as cluster views.
By default, the scheduled job service is using JGroups as the cluster provider, so the
JGroupsLockClusterService is the implementation that is used.
The cluster configuration defines a
RouteBuilder bean named
This is the component responsible for actually invoking the
SchedulerService at repeated intervals to load and schedule any jobs that have not been scheduled.
The component registers a consumer to Apache Camel’s Timer endpoint, which will fire periodically according to the configured polling interval.
When the timer fires and the
Exchange is received, the
SchedulerService will be invoked.
All of this functionality is wrapped in yet another Apache Camel concept called the Master endpoint. The Timer endpoint is invoked through the Master endpoint to guarantee that only one node in the cluster will actually consume the event. This also provides automatic fail-over behavior if the current master dies.
JobClusterService is mainly used as a logging utility.
It is used as part of a "leadership-changed" event listener for the cluster, and logs when the current node becomes the leader or is no longer the leader.
This is useful to determine when a node assumes or releases scheduling responsibilities.
While the scheduled job service is generally agnostic to the actual jobs that need to be scheduled, it does contain specialized components relating to the scheduling and unscheduling of sandboxing deployments.
Listens for messages emitted by the sandbox service on the
scheduleDeployment channel and creates a
ScheduledJob for each one.
Used to schedule sandboxing deployments for a later time.