Cron Trait
The Cron trait can be used to customize the behaviour of periodic timer/cron based integrations.
While normally an integration requires a pod to be always up and running, some periodic tasks, such as batch jobs, require to be activated at specific hours of the day or with a periodic delay of minutes. For such tasks, the cron trait can materialize the integration as a Kubernetes CronJob instead of a standard deployment, in order to save resources when the integration does not need to be executed.
Integrations that start from the following components are evaluated by the cron trait: timer
, cron
, quartz
.
The rules for using a Kubernetes CronJob are the following:
- timer
: when periods can be written as cron expressions. E.g. timer:tick?period=60000
.
- cron
, quartz
: when the cron expression does not contain seconds (or the "seconds" part is set to 0). E.g.
cron:tab?schedule=0/2$+*+*+*+?
or quartz:trigger?cron=0+0/2+*+*+*+?
.
This trait is available in the following profiles: Kubernetes, Knative, OpenShift.
Configuration
Trait properties can be specified when running any integration with the CLI:
$ kamel run --trait cron.[key]=[value] --trait cron.[key2]=[value2] integration.groovy
The following configuration options are available:
Property | Type | Description |
---|---|---|
|
|
Can be used to enable or disable a trait. All traits share this common property. |
|
|
The CronJob schedule for the whole integration. If multiple routes are declared, they must have the same schedule for this mechanism to work correctly. |
|
|
A comma separated list of the Camel components that need to be customized in order for them to work when the schedule is triggered externally by Kubernetes.
A specific customizer is activated for each specified component. E.g. for the Supported components are currently: |
|
|
Use the default Camel implementation of the |
|
|
Specifies how to treat concurrent executions of a Job. Valid values are: - "Allow": allows CronJobs to run concurrently; - "Forbid" (default): forbids concurrent runs, skipping next run if previous run hasn’t finished yet; - "Replace": cancels currently running job and replaces it with a new one |
|
|
Automatically deploy the integration as CronJob when all routes are
either starting from a periodic consumer (only It’s required that all periodic consumers have the same period and it can be expressed as cron schedule (e.g. |
|
|
Optional deadline in seconds for starting the job if it misses scheduled time for any reason. Missed jobs executions will be counted as failed ones. |
|
|
Specifies the duration in seconds, relative to the start time, that the job may be continuously active before it is considered to be failed. It defaults to 60s. |
|
|
Specifies the number of retries before marking the job failed. It defaults to 2. |