This site is in the process of being reviewed and updated.

Introduction

There is a need to schedule events and tasks within the server. We will use Quartz to do this.

Quartz: What is it?

Quartz is a neat embeddable scheduler that we can use to trigger events.

Why do we need it?

ApacheDS needs to schedule certain jobs for execution periodically. Mitosis needs it to purge the replication log and to delete old tomestoned entries. Furthermore mitosis needs a scheduler to manage sophisticated replication schedules for replication groups.

Besides these needs, administrators will want to schedule certain tasks within the server as well. For example the server can be backed up using a trigger to offline then backup the server. We also need it for mandating password policy.

Quartz Integration

A single Quartz Scheduler would be started on ApacheDS core system startup with some configurable number of threads. This way the scheduler based capabilities are available even when networking is not enabled. Once started the scheduler would need to be shutdown on system shutdown.

Access to the Scheduler for the DirectoryService can be made through the DirectoryServiceConfiguration. All interceptor would have access to the Scheduler. A custom Quartz JobStore or a Quartz Plugin can be implemented to store jobs on disk as LDAP entries.

Scheduler Schema

With LDAP entries for storing jobs and triggers we're going to need a custom schema for scheduling information. The rest of this section defines the attributes and objectClasses that will be needed.

A JobDetail has the following attributes:

name
description
group
isDurable
isVolatile
isRecoverable
a Java Class implementing the Job interface
data map entries: key value pairs

All triggers have the following attributes:

name
start time
stop time
group
job name
job group

A trigger has the following attributes if simple:

repeat count
repeat interval

A trigger has the following attributes if it is periodic using the quartz cron notation:

cron expression

Don't forget to parameterize access to start and stop times for cron based triggers.

Quartz internally stores a lot more information related to the created jobs and triggers. One way to achieve LDAP store for quartz is to expose the minimal and required information as entries from the custom store which holds the original data-structures used by quartz in some sort of serialized form.

This frees us from representing and maintaining all the relational aspects of quartz schema in LDAP at the same time allowing to edit the job/trigger configuration through LDAP entries.

One other feature that may be feasible is to create a new job/trigger on the fly by including a beanshell script submitted through the client.

Adding New Job Entries to Scheduler

There are 3 challenges we face with LDAP based jobs and triggers:

how to initially load all LDAP jobs into the scheduler
how to load and unload jobs as new ones are added and old ones are deleted
how to respond to changes in old jobs that have already been loaded

A custom interceptor can be used to detect writes involving trigger/job entries. However this is perhaps overkill. We do not need to do anything before these write operations. All actions to load and unload jobs from the Scheduler can occur after the write has occurred. In this case, the Scheduler can depend on the event service for notifications.

Scheduler Configuration

The Scheduler needs to take various parameters which control it's behavior. These parameters should be added to a configuration entry for the scheduler in the ou=system area. Changes to this entry should automatically reconfigure the Scheduler.

Scheduler Status

The currently running jobs should also be displayed under the configuration entry for the scheduler within the ou=system area of the server.

Quartz RDBMS Schema

All tables' description - quartz-jdbcstore-tables-with-allcolumns.pdf
ER diagram of the quartz's RDBS schema - quartz-jdbcstore-er-diagram.pdf

Quartz Schema

See Quartz Schema