Deciding whether something needs to be done or not is often a job in itself, and Oddjob takes this view too. Rather than have a job that runs if a property is set or a file available, Oddjob has jobs that checks if a property is set (check) or a file is available (exists) and jobs that execute depending on the state of the jobs that did the checking.
There are two main jobs that can be used to do something depending on the outcome of a job. They are:
Trigger was introduced in the scheduling section of this manual, because it was developed sharing a lot of functionality with timer and retry and so was placed in the scheduling namespace. Conceptionally though it is more related to the state jobs and so is included here too.
The big difference between them is that the
if job is synchronous
and state is evaluated after the child job runs, where as the
job is asynchronous. Oddjob activates the trigger then moves on to
execute the next job. The trigger will then fire (or cancel itself)
at some point in the future depending on the state of the job it depends
There are also two jobs that will stop Oddjob from executing anything else until another job is in a certain state. They are:
Both these jobs block Oddjob, which is OK in small configurations but could leave too many threads blocked and thus hog resources in larger deployments. It's nearly always possible to come up with an alternative configuration using other jobs listed on this page.
join job will only continue it's child job has
finished running. The
wait jobs take a property that is a State Condition
that tests states to see if the condition is met. This provides
more flexibility than just checking a job is in a single state. Oddjob
provides a number of useful State Conditions with a conversion from
a text constant (you can set the property with a single word).
The provided State Conditions are:
An '!' can also be place in front of any of these state conditions to negate them.
As stated previously, the
join has it's state condition
hard coded. That value is equivalent to !RUNNING. Note that this is
different to FINISHED because finished does not include the READY state.
Oddjob 1.6 introduces events. The idea is to allow jobs to trigger from events other than state changes.
The starting points are:
Currently supported event types are:
Event logic can be combined with: