object CancellationStrategy extends Serializable
- Alphabetic
- By Inheritance
- CancellationStrategy
- Serializable
- AnyRef
- Any
- Hide All
- Show All
- Public
- Protected
Type Members
- final case class AfterDelay(delay: FiniteDuration, strategy: Strategy) extends Strategy with Product with Serializable
Strategy that allows to delay any action when
cancelStageis invoked.Strategy that allows to delay any action when
cancelStageis 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.
- sealed trait Strategy extends AnyRef
Not for user extension
Not for user extension
- Annotations
- @DoNotInherit()
Value Members
- final def !=(arg0: Any): Boolean
- Definition Classes
- AnyRef → Any
- final def ##: Int
- Definition Classes
- AnyRef → Any
- final def ==(arg0: Any): Boolean
- Definition Classes
- AnyRef → Any
- def afterDelay(delay: Duration, strategy: Strategy): Strategy
Java API
Java API
Strategy that allows to delay any action when
cancelStageis 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.
- final def asInstanceOf[T0]: T0
- Definition Classes
- Any
- def clone(): AnyRef
- Attributes
- protected[lang]
- Definition Classes
- AnyRef
- Annotations
- @throws(classOf[java.lang.CloneNotSupportedException]) @HotSpotIntrinsicCandidate() @native()
- def completeStage: Strategy
Java API
Java API
Strategy that treats
cancelStagethe same ascompleteStage, 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).
- final def eq(arg0: AnyRef): Boolean
- Definition Classes
- AnyRef
- def equals(arg0: AnyRef): Boolean
- Definition Classes
- AnyRef → Any
- def failStage: Strategy
Java API
Java API
Strategy that treats
cancelStagethe same asfailStage, i.e. all inlets are cancelled (propagating the cancellation cause) and all outlets are failed propagating the cause from cancellation. - final def getClass(): Class[_ <: AnyRef]
- Definition Classes
- AnyRef → Any
- Annotations
- @HotSpotIntrinsicCandidate() @native()
- def hashCode(): Int
- Definition Classes
- AnyRef → Any
- Annotations
- @HotSpotIntrinsicCandidate() @native()
- final def isInstanceOf[T0]: Boolean
- Definition Classes
- Any
- final def ne(arg0: AnyRef): Boolean
- Definition Classes
- AnyRef
- final def notify(): Unit
- Definition Classes
- AnyRef
- Annotations
- @HotSpotIntrinsicCandidate() @native()
- final def notifyAll(): Unit
- Definition Classes
- AnyRef
- Annotations
- @HotSpotIntrinsicCandidate() @native()
- def propagateFailure: Strategy
Java API
Java API
Strategy that treats
cancelStagein 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.
- final def synchronized[T0](arg0: => T0): T0
- Definition Classes
- AnyRef
- def toString(): String
- Definition Classes
- AnyRef → Any
- final def wait(arg0: Long, arg1: Int): Unit
- Definition Classes
- AnyRef
- Annotations
- @throws(classOf[java.lang.InterruptedException])
- final def wait(arg0: Long): Unit
- Definition Classes
- AnyRef
- Annotations
- @throws(classOf[java.lang.InterruptedException]) @native()
- final def wait(): Unit
- Definition Classes
- AnyRef
- Annotations
- @throws(classOf[java.lang.InterruptedException])
- case object CompleteStage extends Strategy with Product with Serializable
Strategy that treats
cancelStagethe same ascompleteStage, i.e.Strategy that treats
cancelStagethe same ascompleteStage, 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).
- case object FailStage extends Strategy with Product with Serializable
Strategy that treats
cancelStagethe same asfailStage, i.e.Strategy that treats
cancelStagethe same asfailStage, i.e. all inlets are cancelled (propagating the cancellation cause) and all outlets are failed propagating the cause from cancellation. - case object PropagateFailure extends Strategy with Product with Serializable
Strategy that treats
cancelStagein different ways depending on the cause that was given to the cancellation.Strategy that treats
cancelStagein 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.