Packages

object CancellationStrategy extends Serializable

Annotations
@ApiMayChange()
Source
Attributes.scala
Linear Supertypes
Serializable, Serializable, AnyRef, Any
Content Hierarchy
Ordering
  1. Alphabetic
  2. By Inheritance
Inherited
  1. CancellationStrategy
  2. Serializable
  3. Serializable
  4. AnyRef
  5. Any
  1. Hide All
  2. Show All
Visibility
  1. Public
  2. All

Type Members

  1. final case class AfterDelay(delay: FiniteDuration, strategy: Strategy) extends Strategy with Product with Serializable

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

    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.

    Annotations
    @ApiMayChange()
  2. sealed trait Strategy extends AnyRef

Value Members

  1. object CompleteStage extends Strategy with Product with Serializable

    Strategy that treats cancelStage the same as completeStage, i.e.

    Strategy that treats cancelStage the same as completeStage, i.e. all inlets are cancelled 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).

    Annotations
    @ApiMayChange()
  2. object FailStage extends Strategy with Product with Serializable

    Strategy that treats cancelStage the same as failStage, i.e.

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

    Annotations
    @ApiMayChange()