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.


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 timer component, the cron-timer customizer is activated (it’s present in the org.apache.camel.k:camel-k-cron library).

Supported components are currently: cron, timer and quartz.



Use the default Camel implementation of the cron endpoint (quartz) instead of trying to materialize the integration as Kubernetes CronJob.



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 cron, timer and quartz are supported) or a passive consumer (e.g. direct is a passive consumer).

It’s required that all periodic consumers have the same period and it can be expressed as cron schedule (e.g. 1m can be expressed as 0/1 * * * *, while 35m or 50s cannot).



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.