-
Notifications
You must be signed in to change notification settings - Fork 5
Configuration
This section explains Kronos configuration.
A task definition is composed of a set of attributes some required by the Kronos and some required by the task itself during execution.
KEY | DESCRIPTION | TYPE | DEFAULT | MANDATORY |
---|---|---|---|---|
name | name of the task | string | None | yes |
group | name of the task group that includes all its dependent tasks | string | default | no |
type | type of task | string | None | yes |
isEnabled | enable/ disable a task, disabled tasks won’t be picked by the Kronos for execution | boolean | true | no |
schedule | cron string representing the task schedule | string | None | yes |
maxExecutionTime | max allowed time for the task to finish execution | string | 1d | no |
timeoutPolicy | policy to apply in case of timeout | string | None | no |
dependsOn | list of tasks current task depends on | list | None | no |
properties | properties required by the task handler to execute the task | map | None | no |
name: Identifies the task within a group.
group: name of the group that the task belongs to. This is similar to a namespace and can be used to isolate tasks across workflows. This feature is useful in a multi-tenant deployment where the workflow definition is same across tenants. Defining the group name same as the tenant id or name allows the same workflow definition to be re-used across tenants avoiding the need for separate deployment of Kronos across tenants.
type: Tasks of the same type are executed by the same handler. The task type is associated with a handler as part of the handler configuration.
isEnabled: By default enabled, can be turned off to remove the definition out of the Kronos. Note that if a task is disabled, all other tasks that depend on this task are marked failed.
schedule: Defines the time at which the task is to be scheduled for execution, represented as a cron string. One can use cronmaker to build simple cron string. For more details on supported cron string format check out this link.
maxExecutionTime The user can define a maximum time a task is allowed to take for its execution. Post the defined time, the task is marked as failed and if a timeout policy is configured then it is executed. Note, the task execution is not affected either by this configuration or the timeout policy.
timeoutPolicy The user can specify a policy to execute on task timeout. A task is said to be timed out if it fails to respond back within the specified max execution time.
dependsOn Defines a list of tasks it depends on. The dependant tasks are identified by their names. Dependency between two task is defined as -
KEY | DESCRIPTION | TYPE | DEFAULT | MANDATORY |
---|---|---|---|---|
name | name of the task it depends on | string | None | yes |
duration | look for the tasks with the specified name in the specified duration | string | None | yes |
mode | specify if it depends on the first, last or all tasks found in the duration period | enum | all | no |
mode can be
-
first
which means the first instance in the specified duration -
last
means the last instance in the specified duration -
all
means all the instance in the specified duration.
Duration can be defined as 5s/m/h/d
, where m
stand for minutes, h
for hour, s
for seconds and d
for days. If none is passed it is assumed to be in milliseconds.
Sample task definitions where weekly aggregation task depends on daily and hourly aggregation task.
- name: Hourly Aggregation
# task type
type: aggregation
schedule: 0 0 0/1 1/1 * ? *
properties:
key: value
...
- name: Daily Aggregation
# task type
type: aggregation
schedule: 0 0 0 1/1 * ? *
properties:
key: value
...
- name: Weekly Aggregation
# task type
type: aggregation
schedule: 0 0 0 ? * SUN *
dependsOn:
- name: Hourly Aggregation
duration: 7d
mode: all
dependsOn:
- name: Daily Aggregation
duration: 7d
mode: all
...
properties:
key: value
...
Note: These YAML based task definitions are read by the file based task reader extension.
properties
Additional properties might be required by the handler to execute this task. These properties will be passed on to the handler as part of task properties. Properties is a map of key-value pairs, where the key is string and value can be any object.
The user can define custom reader to read task definitions from an external source. The user can define multiple task definition readers. The task definition readers are configured in the main configuration file app.yaml
under readerConfig
section. The user can also define a custom reader.
KEY | DESCRIPTION | TYPE | DEFAULT | MANDATORY |
---|---|---|---|---|
readerClass | fully qualified class name of the TaskDefinitionReader implementation | string | None | yes |
schedule | A cron schedule to refresh the task definitions from the source | string | None | yes |
config | additional configuration required by the reader during instantiation | objectnode | None | no |
Sample configuration
readerConfig:
# name to be assigned to the reader
filereader:
# fully qualified classname of the TaskDefinitionReader.java implementation
readerClass: com.cognitree.kronos.scheduler.readers.FileTaskDefinitionReader
# additional configuration
config:
source: task-definitions.yaml
# interval in cron to look for changes in the task definition file
schedule: 0 0/1 * 1/1 * ? *
For each type of task, a handler needs to be configured to execute the task. A handler is configured in the main configuration file app.yaml
under handlerConfig
section. The user can also define a custom handler.
KEY | DESCRIPTION | TYPE | DEFAULT | MANDATORY |
---|---|---|---|---|
handlerClass | fully qualified class name of the TaskHandler implementation | string | None | yes |
config | additional configuration required by the handler during instantiation | objectnode | None | no |
maxExecutionTime | max allowed time for the task to finish execution if not explicitly specified by task | string | 1d | no |
timeoutPolicy | policy to apply in case of timeout if not explicitly specified by task | string | None | no |
maxParallelTasks | max number of tasks allowed to be executed in parallel | string | max cores/2 | no |
# configure task handlers
handlerConfig:
# type of task to be handled by handler
shellCommand:
# handler implementation used to handle task of type shellCommand
handlerClass: com.cognitree.kronos.executor.handlers.ShellCommandHandler
# max execution time per task
maxExecutionTime: 10m
# max parallel tasks handler is allowed to execute at any point of time
default:
handlerClass: com.cognitree.kronos.executor.handlers.DefaultHandler
# max parallel tasks handler is allowed to execute at any point of time
maxParallelTasks: 8
In the above sample, Shell Command Handler is configured to handle tasks of type shellCommand
. The user can also configure a default handler for the task type(s) that do not have a handler defined here defined as default
.
Note: default
is a special keyword used to define default handler.
Message Bus is used by scheduler and executor to exchange messages. A message bus (Producer/ Consumer) is configured for task and task status in app.yaml
. The user can provide a custom implementation of message bus.
Producer
KEY | DESCRIPTION | TYPE | DEFAULT | MANDATORY |
---|---|---|---|---|
producerClass | fully qualified class name of the Producer implementation | string | None | yes |
config | additional configuration required by the producer during instantiation | objectnode | None | no |
Consumer
KEY | DESCRIPTION | TYPE | DEFAULT | MANDATORY |
---|---|---|---|---|
consumerClass | fully qualified class name of the Consumer implementation | string | None | yes |
config | additional configuration required by the consumer during instantiation | objectnode | None | no |
# configure message bus
## configure task producer
taskProducerConfig:
producerClass: com.cognitree.kronos.queue.producer.InMemoryTaskProducer
## configure task consumer
taskConsumerConfig:
consumerClass: com.cognitree.kronos.queue.consumer.InMemoryTaskConsumer
config:
pollInterval: 10s # time interval to poll tasks from task queue for execution
## configure task status producer
taskStatusProducerConfig:
producerClass: com.cognitree.kronos.queue.producer.InMemoryStatusProducer
## configure task status consumer
taskStatusConsumerConfig:
consumerClass: com.cognitree.kronos.queue.consumer.InMemoryStatusConsumer
config:
pollInterval: 10s # time interval to poll tasks status from status queue
In the above sample, an in-memory message bus is configured.
A task store is used to store the current state of the Kronos application. A task store is configured in the main configuration file app.yaml
file under storeProvider
section. The user can provide a custom implementation of task store.
KEY | DESCRIPTION | TYPE | DEFAULT | MANDATORY |
---|---|---|---|---|
taskStoreClass | fully qualified class name of the TaskStore implementation | string | None | yes |
config | additional configuration required by the task store during instantiation | objectnode | None | no |
taskStoreConfig:
taskStoreClass: com.cognitree.kronos.store.SQLiteTaskStore
config:
connectionURL: jdbc:sqlite:tasks.db
username: SA
password: password
In the above sample, a sqlite task store is configured.
Define policies to apply in case of task timeout. A timeout policy is configured in the main configuration file app.yaml
file under timeoutPolicyConfig
section. The user can provide implementation of timeout policy.
KEY | DESCRIPTION | TYPE | DEFAULT | MANDATORY |
---|---|---|---|---|
policyClass | fully qualified class name of the TimeoutPolicy implementation | string | None | yes |
config | additional configuration required by the timeout policy during instantiation | objectnode | None | no |
timeoutPolicyConfig:
notifyOnTimeout:
policyClass: com.cognitree.examples.tasks.scheduler.policies.NotifyOnTimeoutPolicy
config:
smtp.host: "smtp.gmail.com"
smtp.port: 587
sender.name:
sender.email:
sender.password:
email.subject: "Task Timeout notification"
recipient.name:
recipient.email:
In the above sample, notifyOnTimeout
is the policy identifier that is to be used while defining the task definition and/or task handler as the timeout policy.
Periodically, tasks older than the specified interval and status in one of the final state are purged from memory. The task purge interval is configured in the main configuration file app.yaml
under taskPurgeInterval
section.
KEY | DESCRIPTION | TYPE | DEFAULT | MANDATORY |
---|---|---|---|---|
taskPurgeInterval | purge interval (1d, 1h 15m etc) | string | 1d | no |
taskPurgeInterval: 6h
In the above sample, the task purge interval period is configured as 6 hours.