The previous section defined a component that would schedule a task to print Hello! to the console. To schedule this task, the component needs to be configured with a pointer to the Scheduler, and a schedule. The following is an example of such a configuration file:
scheduler=/atg/dynamo/service/Scheduler
schedule=every 10 seconds
The scheduler property makes sense, since it just points to the standard Dynamo Scheduler. The schedule property, however, might be a little more surprising. This works because a PropertyEditor is defined for the Schedule type, so Dynamo can understand a wide variety of schedule definitions.
The different types of Schedules can also be created programmatically by creating new instances of RelativeSchedule, PeriodicSchedule, or CalendarSchedule.
RelativeSchedule
A RelativeSchedule specifies a time relative to the current time. For example, the following specifies a task that will occur in 30 seconds:
schedule=in 30 seconds
The time units may be any one of the following:
msec
sec
seconds
min
minute
minutes
hour
hours
day
days
PeriodicSchedule
A PeriodicSchedule specifies a task that will occur at regular intervals. There are three parameters for this Schedule. The first is the period between jobs. For example:
schedule=every 20 minutes
A second parameter lets you specify a period to wait before starting the schedule:
schedule=every 10 seconds in 20 minutes
This will wait 20 minutes before starting the periodic task. Once it starts, it executes every 10 seconds.
The third parameter determines whether or not the PeriodicSchedule should attempt to catch up if it misses jobs. For example, suppose that the period is 2 seconds. Now assume that the job occurs at time A. Another job should occur at time A+2. But suppose that the Scheduler doesn’t get around to handling the job until time A+5. This might happen if the polling interval is greater than the job’s period (technically, this will occur if the polling interval is greater than half the period). The next time it will schedule for the job is A+6, which means that the job at A+4 is missed.
By default, the schedule is executed without catch up. Only by explicitly stating with catch up will missed jobs be executed. If the PeriodicSchedule is instructed to catch up, then at time A+5, the job will occur twice, once for A+2, and once for A+4. The next job will occur at A+6. If the PeriodicSchedule is instructed not to catch up, then the job that would have occurred at A+4 will be discarded. The following example sets a PeriodicSchedule that will catch up missed jobs:
schedule=every 10 seconds in 20 minutes with catch up
CalendarSchedule
A CalendarSchedule specifies a task that will occur according to units of the calendar and clock. For example, you can schedule a task to occur at 2:30am on the 1st and 15th of every month. The format looks like this:
schedule=calendar <months> <dates> <days of week>
<occurrences in month> <hours> <minutes>
The parameters are specified as follows:
months | The months in which the task is to occur (0 = January, 11 = December). |
|---|---|
dates | The days of the month on which the task is to occur. The days range from 1 to 31. |
days of week | The days of the week on which the task is to occur (1 = Sunday, 7 = Saturday). |
occurrences in month | The occurrences of the days of the week in the month. For example, you can specify that a task should occur on the 1sst and 3rd Wednesdays of the month. Valid values are 1, 2, 3, 4, and last. |
hours | The hours of the day on which the task is to occur (0-23, 0 = midnight). |
minutes | The minutes of the hour in which the task is to occur (0-59). |
For each of the fields, multiple entries may be specified by separating the values with commas. A range of entries may be selected by separating two values with a dash (wraparound is allowed). For example, in the months field:
4,7,11-2
This would specify the months May, August, December, January, February, and March.
A * entry selects all values for that field. A period (.) selects no values.
Using the CalendarSchedule, a task will be performed if all of the conditions are met:
the current month matches one of the month entries
one of the following is true:
the current day of the month matches one of the date entries,
the current day of the week matches one of the day of the week entries and its occurrence in the month matches one of the occurrence in month entries
the current hour matches one of the hour entries
the current minute matches one of the minute entries
Here are a few examples:
A task that occurs at 2:05pm on the 1st and 15th of every month:
calendar * 1,15 . * 14 5
A task that occurs at 2:05pm on the 1st and last Sunday of every month:
calendar * . 1 1,last 14 5
A task that occurs every day in February at 1am and 1pm:
calendar 1 * . * 1,13 0
A task that occurs every hour on the hour every Monday in June:
calendar 5 . 2 * * 0
A task that occurs 9-5 on the half hour every day:
calendar * * * * 9-17 30
Backwards Compatibility in CalendarSchedules
The occurrences in month field of the CalendarSchedule was added in Dynamo 5.0. Earlier versions of Dynamo used a 5-field CalendarSchedule. This 5-field format is still supported; a CalendarSchedule with 5 fields is interpreted as having an occurrences in month value of *.
