Major Description
Tasks are partitioned and placed based on a target resource. An explicit set of partitions or partition states may also be specified.
Tasks can be paused, resumed and deleted (the message handlers are still being worked on — for the time being, the test cases directly set zk state).
Task resources and associated state are expired out of zk after a configured amount of time has elapsed since it was created. This is a per-task configuration.
The number of concurrent tasks that run per instance is configurable.
The only error policy available right now is to fail the entire task if any single task partition fails a configured number of times.
The Task state model is as follows:
init
+
v
------------------+running-----------------------------+
| + + + | |||
| -------------------- | |||
| ---- |
v v v v v
stopped completed timed_out task_error error
+ + + + +
| ---- |
|||
| -------------------- | |||
| v v v |
-----------------> dropped <----------------------------
"init" is the initial state of a task partition.
"stopped" indicates that task partition is partially done but was stopped by the controller.
"completed" indicates that the task partition is complete.
"timed_out" indicates that the task partition did not complete within a configured time out value.
"task_error" indicates that the task partition encountered an error during execution.
"error" and "dropped" are helix internal states.
The "init" to "running" transition does not wait for the task to finish execution on the participant. The participant requests state changes (to "completed" or "timed_out" or "task_error") via a "REQUESTED_STATE" property in the CURRENTSTATE znode.
If the participant session is reset, all on-going tasks are stopped.