AbstractOrchestrator
Related Doc:
package akkastrator
The type of Id this orchestrator handles.
Computes ID from the deliveryId of akka-persistence.
Converts ID to the deliveryId needed for the confirmDelivery method of akka-persistence.
Ensures the received message was in fact destined to be received by task.
We use a HashMap to ensure remove/insert operations are very fast O(eC).
We use a HashMap to ensure remove/insert operations are very fast O(eC). The keys are the task indexes.
Override this method to add extra commands that are always handled by this orchestrator (except when recovering).
How many tasks of this orchestrator have successfully finished.
How many tasks of this orchestrator have successfully finished. Aborted tasks do not count as a finished task.
User overridable callback.
User overridable callback. Its called when the orchestrator is aborted. By default an orchestrator
aborts as soon as a task aborts. However this functionality can be changed by overriding onTaskAbort.
By default logs that the orchestrator has aborted, sends a message to its parent explaining why the orchestrator aborted then stops it.
You can use this to implement your termination strategy.
User overridable callback.
User overridable callback. Its called after every task finishes. If a task aborts then it will prevent this method from being invoked.
By default logs that the Orchestrator has finished then stops it.
You can use this to implement your termination strategy.
If a orchestrator starts without tasks it will finish right away.
User overridable callback.
User overridable callback. Its called after the orchestrator starts but before any of the tasks start.
By default logs that the Orchestrator has started.
User overridable callback.
User overridable callback. Its called every time a task aborts.
You can use this to implement very refined termination strategies.
By default aborts the orchestrator via onAbort with a TaskAborted failure.
Note: if you invoke become/unbecome inside this method, the contract that states "Waiting tasks or tasks which do not have this task as a dependency will remain untouched" will no longer be guaranteed. If you wish to still have this guarantee you can do
context.become(computeCurrentBehavior() orElse yourBehavior)
{ @see onTaskStart} for a callback when a task starts. { @see onTaskFinish } for a callback when a task finishes.
the task that aborted.
User overridable callback.
User overridable callback. Its called every time a task finishes.
You can use this to implement very refined termination strategies.
By default just logs the task has finished.
{ @see onTaskStart} for a callback when a task starts. { @see onTaskAbort} for a callback when a task aborts.
User overridable callback.
User overridable callback. Its called every time a task starts.
By default just logs the task as started.
{ @see onTaskFinish} for a callback when a task finishes. { @see onTaskAbort} for a callback when a task aborts.
This exists to make the creation of FullTasks easier.
the settings to use for this orchestrator.
An Orchestrator executes a set of, possibly dependent,
Tasks. A task corresponds to sending a message to an actor, handling its response and possibly mutate the internal state of the Orchestrator.The Orchestrator together with the Task is able to:
DistinctIdsOrchestratorensures each destination will see an independent strictly monotonically increasing sequence number without gaps.NOTE: the responses that are received must be Serializable.
In order for the Orchestrator and the Tasks to be able to achieve all of this they have to access and modify each others state directly. This means they are very tightly coupled with each other. To make this relation more obvious and to enforce it, you will only be able to create tasks if you have a reference to an orchestrator (which is passed implicitly to a task).
If you have the need to refactor the creation of tasks so that you can use them in multiple orchestrators you can leverage self type annotations.
the type of result this orchestrator returns when it finishes.