Documentation

Job submission is triggered by the Quartz scheduler, which, if not on the zookeeper leader, does not initiate job execution, for the reasons discussed above. If the scheduler is on the zookeeper leader, then the execution of the job is delegated to a thread, which waits until the end of the job to save information about its execution. The flow of actions to be supported is detailed by the activity diagram below.

Fire job activity diagram

HyperIoTJobScheduler Module

HyperIoTJobScheduler does not differ in terms of organization from other HyperIoT framework projects.

Job Scheduler Hierarchy

In the diagram is possibile to see the module and its dependencies toward the Quartz module and the ZookeeperConnectorSystemApi interface, which provides the method for determining whether the scheduler resides on the cluster leader node.

A dedicated discussion is addressed regarding the following:

• HyperIoTJob interface;
• Methods exposed by the JobSchedulerSystemApi interface.

HyperIoTJob Interface

Jobs in HyperIoT are of type HyperIoTJob. Actually, because HyperIoT uses the Quartz scheduler, one could have simply used the org.quartz.Job type, however, we wanted to introduce the link between HyperIoT and jobs through a dedicated type. Details of the methods exposed by the interface follow, compared to the implementation of the interface provided by default by HyperIoT:

• String getClassName(): returns the name of the class that implements the org.quartz.Job interface. HyperIoT currently supports jobs running on Spark, which is why this the classname will refer to the class that extends the abstract HyperIoTSparkJob, which implements the org.quartz.Job interface.
• String getCronExpression(): provides the cron expression of the job.
• JobDetail getJobDetail(): returns the details of a job, via an implementation of the org.quartz.JobDetail class (in this case, the one provided by the org.quartz.JobBuilder).
• JobKey getJobKey(): returns the job identifier, i.e., an instance of the org.quartz.JobDetail class.
• Map<String, Object> getJobParams(): provides additional parameters of the job (example: the id of the HProject for which the job was defined);
• boolean isActive(): returns true if the job is active, false otherwise.

Job Scheduler System Api

The interface in question defines the methods that allow interaction with the Quartz scheduler. Details for each follow, compared to the implementation of the interface provided by default by HyperIoT:

• void addJob(HyperIoTJob job): adds the job, if it does not exist, to the Quartz scheduler. If the job is active, it is also scheduled, subject to validation of its cron expression;
• void deleteJob(HyperIoTJob job): deletes the job, if it exists, from the Quartz scheduler;
• void updateJob(HyperIoTJob job): if the job exists, updates it. It also modifies its cron expression, if active, to support the update relative to its scheduling.

Job Submission

Having defined the job in HyperIoT, and thus the structure of the sub-modules that make up the broader HyperIoTJobScheduler, the sequence diagram that follows provides a high-level overview of the interactions involved regarding the job submission.

Job Submission

Configurations

In the Karaf distribution there is the file en.acsoftware.hyperiot.scheduler.cfg for module configuration.

The properties in the file follow: