This link is no longer relevant as we now have a jobboard method that can trash() jobs so that they can not be claimed again. Change-Id: I087a90c16b95e9b80a37863fa79f3348fa448bdf
2.3 KiB
Conductors
Overview
Conductors in TaskFlow provide a mechanism that unifies the various TaskFlow concepts under a single easy to use (as plug-and-play as we can make it) construct.
They are responsible for the following:
- Interacting with
jobboards <jobs>
(examining and claimingjobs <jobs>
). - Creating
engines <engines>
from the claimed jobs (usingfactories <resumption factories>
to reconstruct the contained tasks and flows to be executed). - Dispatching the engine using the provided
persistence <persistence>
layer and engine configuration. - Completing or abandoning the claimed job (depending on dispatching and execution outcome).
- Rinse and repeat.
Note
They are inspired by and have similar responsibilities as railroad conductors.
Considerations
Some usage considerations should be used when using a conductor to make sure it's used in a safe and reliable manner. Eventually we hope to make these non-issues but for now they are worth mentioning.
Endless cycling
What: Jobs that fail (due to some type of internal error) on one conductor will be abandoned by that conductor and then another conductor may experience those same errors and abandon it (and repeat). This will create a job abandonment cycle that will continue for as long as the job exists in an claimable state.
Example:
Alleviate by:
- Forcefully delete jobs that have been failing continuously after a
given number of conductor attempts. This can be either done manually or
automatically via scripts (or other associated monitoring) or via the
jobboards :py
~taskflow.jobs.base.JobBoard.trash
method. - Resolve the internal error's cause (storage backend failure, other...).
Interfaces
taskflow.conductors.base
Implementations
taskflow.conductors.backends
taskflow.conductors.backends.impl_blocking
Hierarchy
taskflow.conductors.base taskflow.conductors.backends.impl_blocking