Apache Cocoon 2.1.12

This implementation of the Java interface JobScheduler is based on the Quartz job scheduling project and the RunnableManager as a ThreadPool implementation for the Quartz Scheduler.

WARNING: Consider the JobScheduler interface as beta in terms of defined functionality as it will be extended with additional requirements in the near future (i.e. getJobList).

This QuartzJobScheduler implementation is written as a standard Avalon component. So, its definition you'll find in the cocoon.xconf file of Cocoon if you've included the cron-block in your build (see block.properties or local.block.properties file respectively).

There is nothing special about it. As you could see from the snippet above, inside the job scheduler component definition there are two parts:

ThreadPool

<!-- Definitions for a thread pool used to schedule jobs -->
<thread-pool>

    <!-- Should we queue up execution requests if the pool is busy? Defaults to false -->
    <use-queueing>false</use-queueing>

    <!-- How big should the queue be. Defaults to unlimited size (<0 == default) -->
    <queue-size>-1</queue-size>

    <!-- The maximum size of the pool. Defaults to Integer.MAX_VALUE (<0 == default) -->
    <max-pool-size>-1</max-pool-size>

    <!-- The minimum size of the pool.Defaults to 1 (<0 == default) -->
    <min-pool-size>1</min-pool-size>

    <!-- How long will an idle thread be kept before it will be discarded. 
         Defaults to 60000ms (<0 == default) -->
    <keep-alive-time-ms>60000</keep-alive-time-ms>

    <!-- Which blocking policy should be used if the maximum pool size and queue size is bounded:
         Run:           (default) The thread making the execute request runs the task itself. 
                        This policy helps guard against lockup. 
         Wait:          Wait until a thread becomes available. 
         Abort:         Throw a RuntimeException 
         Discard:       Throw away the current request and return. 
         DiscardOldest: Throw away the oldest request and return. -->
    <block-policy>RUN</block-policy>

    <!-- Should queued and running jobs be given a chance to finished on system shutdown. Defaults to true -->
    <shutdown-graceful>true</shutdown-graceful>

    <!-- The maximum time to wait for running jobs to complete. Defaults to unlimited time (<0 == default) -->
    <shutdown-wait-time-ms>5000</shutdown-wait-time-ms>
</thread-pool>

As mentioned in the beginning, more information about the thread pool details base on the RunnableManager#createPool(...) method can be found there.

Triggers

The trigger definition section consists of a single <triggers> element with as much as needed <trigger> elements inside it. A <trigger> element looks like:

<!-- Definintions of triggers -->
<triggers>

    <!-- A trigger element has the following attributes:
            name:            A name for the trigger. Mandatory
            target:          A role name to lookup the job object in the ServiceManager. Mandatory
            concurrent-runs: Is it allowed to reschedule a job even if the previous one is
                             still running. Optionl, defaults to true.
         A trigger element has the following child elements:
            cron: A string expression defining the scheduling timing.
                  Optional. If not specified the following elements are explored:
               seconds:  A string expression for the secods part of a cron expression.
               minutes:  A string expression for the secods part of a cron expression.
               hours:    A string expression for the secods part of a cron expression.
               days:     A string expression for the secods part of a cron expression.
               month:    A string expression for the secods part of a cron expression.
               weekdays: A string expression for the secods part of a cron expression.
               years:    A string expression for the secods part of a cron expression.
            For detailed information about the expressions look at the documentation
    -->

    <trigger name="test-job1"
             target="org.apache.cocoon.components.cron.CronJob/test"
             concurrent-runs="false">
        <cron>*/12 * * * * ? *</cron>
    </trigger>
    <trigger name="test-job2"
         target="org.apache.cocoon.components.cron.CronJob/test"
         concurrent-runs="true">
        <seconds>*/12</seconds>
        <minutes>*/5</minutes>
        <hours>8,10,12,14,16,18</hours>
        <days>?</days>
        <months>*</months>
        <weekdays>SUN-FRI</weekdays>
    </trigger>
</triggers>

The <cron> element is simply the concatenation of the values of the elements <seconds>, <minutes>, <hours>, <days>, <months>, <weekdays>, and <year> delimeted with spaces. You can use either form but the <cron> element will be preferred by the implementation if you use both forms together in one <trigger> element. A description of the expressions used inside the <trigger> elements is described in the CronTrigger class.

Job Components

The CronJob object doing your work can be defined in the cocoon.xconf file as a regular Avalon components. The role attribute given to this component is refered to by the target attribute in the <trigger> element above. Below is the sample for the TestCronJob component.

<!-- sample definition of cron job -->
<component role="org.apache.cocoon.components.cron.CronJob/test"
           class="org.apache.cocoon.components.cron.TestCronJob"
           logger="cron.test">
    <msg>I'm here</msg>
    <sleep>23000</sleep>
</component>

Samples

Now you should take a look at the samples to show you how the API of the JobScheduler can be used.

Cron Job Scheduler

ThreadPool

Triggers

Job Components

Samples