-
Notifications
You must be signed in to change notification settings - Fork 5
Configuration
This section explains Kronos configuration.
Scheduler configuration is defined in scheduler.yaml
file and is picked by the Kronos from classpath to initialize and start the scheduler.
A pluggable persistence store to maintain the state of the system.
A store is configured in the scheduler.yaml
file under storeServiceConfig
section and is used to store the state of Kronos. The user can also provide a custom implementation of store.
KEY | DESCRIPTION | TYPE | DEFAULT | MANDATORY |
---|---|---|---|---|
storeServiceClass | fully qualified class name of the StoreService implementation | string | None | yes |
config | additional configuration required by the store provider during instantiation | objectnode | None | no |
storeServiceConfig:
storeServiceClass: com.cognitree.kronos.scheduler.store.jdbc.StdJDBCStoreService
config:
connectionUrl: jdbc:hsqldb:hsql://localhost/tmp/kronos
driverClass: org.hsqldb.jdbcDriver
username: kronos
password: kronos123
In the above sample, a standard jdbc store is configured.
Kronos can be configured to send email notifications to a number of recepients if a job is successful or failed. A email service is configured in the scheduler.yaml
file under mailConfig
section and is used to send the email notifications.
KEY | DESCRIPTION | TYPE | DEFAULT | MANDATORY |
---|---|---|---|---|
smtpHost | smtp server host | string | None | yes |
port | smtp server port | int | None | yes |
userEmail | email address to use to send email | string | None | yes |
password | password to use for the above email address | string | None | yes |
fromName | name to set as from while sending email |
string | None | yes |
fromEmail | email to set as frome while sending email |
string | None | yes |
replyTo | set the reply to address while sending email | string | fromEmail | no |
Note: Recepient for email notification is configured at a workflow level. Check creating workflow guide for more details.
Executor configuration is defined in executor.yaml
file and is picked by the Kronos from classpath to initialize and start the executor.
For each type of task, a handler needs to be configured to execute the task. A handler is configured in the executor.yaml
file under handlerConfig
section. The user can also implement and configure a custom task handler to handle tasks.
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 |
maxParallelTasks | max number of tasks allowed to be executed in parallel | string | max cores/2 | no |
# configure task handlers
taskHandlerConfig:
# type of task to be handled by the handler
shellCommand:
# handler implementation used to handle the task of type shellCommand
handlerClass: com.cognitree.kronos.executor.handlers.ShellCommandHandler
# max parallel tasks handler is allowed to execute at any point in time
maxParallelTasks: 4
In the above sample, Shell Command Handler is configured to handle tasks of type shellCommand
.
The queue is used by the scheduler and executor to exchange messages. A producer and a consumer for the queue is to be configured in queue.yaml
. The user can provide a custom implementation of queue.
A producer for the queue is configured in the queue.yaml
file under producerConfig
section.
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 |
A producer for the queue is configured in the queue.yaml
file under consumerConfig
section.
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 |
Kronos uses a set of topic for its internal communication between scheduler and the executor. These topic are configured in the queue.yaml
file.
| KEY | DESCRIPTION | TYPE | DEFAULT | MANDATORY | | taskStatusQueue | topic name to use to exchange task status updates | string | None | yes | | controlMessageQueue | topic name to use to exchange control messages | string | None | yes | | pollIntervalInMs | time duration between successive poll to queue in millisecond | long | None | yes |
# configure producer and consumer for the queue
producerConfig:
producerClass: com.cognitree.kronos.queue.producer.InMemoryProducer
consumerConfig:
consumerClass: com.cognitree.kronos.queue.consumer.InMemoryConsumer
taskStatusQueue: taskstatus
controlMessageQueue: controlmessages
pollIntervalInMs: 5000
In the above sample, an in-memory queue is configured.