Broadleaf Microservices
  • v1.0.0-latest-prod

Key Components


These are the key components that are relevant for scheduling purposes.


Manage ScheduledJob (and implicitly ScheduledJobDetail) entity instances by handling basic CRUD operations.


Responsible for querying the datastore and building/scheduling Quartz jobs for each ScheduledJob. Once the Quartz jobs are scheduled in its JobStore, Quartz assumes responsibility of firing them at the appropriate time.


DefaultQuartzJob is not registered as a Spring bean (and therefore not technically a "component"), but it is essential nonetheless to document here.

This is the default implementation of a Quartz job which SchedulerService will build for each ScheduledJob. Quartz will invoke the job’s execute() method at the scheduled time.

The 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 schedulerConfig. 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.


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


Listens for messages emitted by the sandbox service on the unscheduleDeployment channel and deletes the ScheduledJob for each one. Used to unschedule previously scheduled sandboxing deployments.