CancellationStrategy

Strategy that allows to delay any action when cancelStage is invoked.

The idea of this strategy is to delay any action on cancellation because it is expected that the stage is completed through another path in the meantime. The downside is that a stage and a stream may live longer than expected if no such signal is received and cancellation is invoked later on. In streams with many stages that all apply this strategy, this strategy might significantly delay the propagation of a cancellation signal because each upstream stage might impose such a delay. During this time, the stream will be mostly "silent", i.e. it cannot make progress because of backpressure, but you might still be able observe a long delay at the ultimate source.

Strategy that treats cancelStage the same as completeStage, i.e. all inlets are cancelled (propagating the cancellation cause) and all outlets are regularly completed.

This used to be the default behavior before Akka 2.6.

This behavior can be problematic in stacks of BidiFlows where different layers of the stack are both connected through inputs and outputs. In this case, an error in a doubly connected component triggers both a cancellation going upstream and an error going downstream. Since the stack might be connected to those components with inlets and outlets, a race starts whether the cancellation or the error arrives first. If the error arrives first, that's usually good because then the error can be propagated both on inlets and outlets. However, if the cancellation arrives first, the previous default behavior to complete the stage will lead other outputs to be completed regularly. The error which arrive late at the other hand will just be ignored (that connection will have been cancelled already and also the paths through which the error could propagates are already shut down).

Strategy that treats cancelStage the same as failStage, i.e. all inlets are cancelled (propagating the cancellation cause) and all outlets are failed propagating the cause from cancellation.

Strategy that treats cancelStage in different ways depending on the cause that was given to the cancellation.

If the cause was a regular, active cancellation (SubscriptionWithCancelException.NoMoreElementsNeeded), the stage receiving this cancellation is completed regularly.

If another cause was given, this is treated as an error and the behavior is the same as with failStage.

This is a good default strategy.

The names of the product elements

The name of the type

Java API

Strategy that allows to delay any action when cancelStage is invoked.

The idea of this strategy is to delay any action on cancellation because it is expected that the stage is completed through another path in the meantime. The downside is that a stage and a stream may live longer than expected if no such signal is received and cancellation is invoked later on. In streams with many stages that all apply this strategy, this strategy might significantly delay the propagation of a cancellation signal because each upstream stage might impose such a delay. During this time, the stream will be mostly "silent", i.e. it cannot make progress because of backpressure, but you might still be able observe a long delay at the ultimate source.

Java API

Strategy that treats cancelStage the same as completeStage, i.e. all inlets are cancelled (propagating the cancellation cause) and all outlets are regularly completed.

This used to be the default behavior before Akka 2.6.

This behavior can be problematic in stacks of BidiFlows where different layers of the stack are both connected through inputs and outputs. In this case, an error in a doubly connected component triggers both a cancellation going upstream and an error going downstream. Since the stack might be connected to those components with inlets and outlets, a race starts whether the cancellation or the error arrives first. If the error arrives first, that's usually good because then the error can be propagated both on inlets and outlets. However, if the cancellation arrives first, the previous default behavior to complete the stage will lead other outputs to be completed regularly. The error which arrive late at the other hand will just be ignored (that connection will have been cancelled already and also the paths through which the error could propagates are already shut down).

Java API

Strategy that treats cancelStage the same as failStage, i.e. all inlets are cancelled (propagating the cancellation cause) and all outlets are failed propagating the cause from cancellation.

Java API

Strategy that treats cancelStage in different ways depending on the cause that was given to the cancellation.

If the cause was a regular, active cancellation (SubscriptionWithCancelException.NoMoreElementsNeeded), the stage receiving this cancellation is completed regularly.

If another cause was given, this is treated as an error and the behavior is the same as with failStage.

This is a good default strategy.