Orders the stream within a sliding window of maxBounded elements.
Only pass on those elements that have not been seen so far.
Only pass on those elements that have not been seen so far.
Emits when the element is not a duplicate
Backpressures when the element is not a duplicate and downstream backpressures
Completes when upstream completes
Cancels when downstream cancels
A linear GraphStage that is used to capture (downstream) demand and (upstream) supply metrics for backpressure visibility.
Exception thrown when an element times out.
Exception thrown when an element times out.
Defaults to "Flow timed out!"
MutableLong is used to avoid boxing/unboxing and also to avoid java.util.Map#put operation to increment the counters in the registry.
A bidi GraphStage that can be joined with flows that produce Try's to add Retry functionality when there are any failures.
A bidi GraphStage that can be joined with flows that produce Try's to add Retry functionality when there are any failures. When the joined Flow has a failure then based on the provided max retries count, it will retry the failures.
Emits when a Success is available from joined flow or a failure has been retried the maximum number of retries
Backpressures when the element is not a failure and downstream backpressures or the retry buffer is full
Completes when upstream completes
Cancels when downstream cancels
upstream +------+ downstream (In, Context) ~> | | ~> (In, Context) In1 | bidi | Out1 (Try[Out], Context) <~ | | <~ (Try[Out], Context) Out2 +------+ In2
the type of elements pulled from the upstream along with the Context
the type of the elements that are pushed by the joined Flow along with the Context. This then gets wrapped with a Try and pushed downstream with a Context
the type of the context that is carried around along with the elements.
A Retry Settings class for configuring a Retry
A Retry Settings class for configuring a Retry
Retry functionality requires each element passing through is uniquely identifiable for retrying, so it requires a Context, of any type carried along with the flow's input and output element as a Tuple2 (Scala) or Pair (Java). The requirement is that either the Context type itself or a mapping from Context should be able to uniquely identify each element passing through flow.
Here are the ways a unique id can be provided:
uniqueIdMapper
the type of elements pulled from upstream along with the Context
the type of the elements that are pushed to downstream along with the Context
the type of the context that is carried along with the elements.
a RetrySettings with specified values
A bidi GraphStage that is joined with flows to add timeout functionality.
A bidi GraphStage that is joined with flows to add timeout functionality. This bidi stage is used with flows that do not guarantee the message ordering. So, it requires a context to be carried along with the elements to uniquely identify each element.
Emits when an element is available from the joined Flow or an element has already timed out
Backpressures when the downstream backpressures
Completes when upstream completes
Cancels when downstream cancels
+------+ (In, Context) ~> | | ~> (In, Context) | bidi | (Try[Out], Context) <~ | | <~ (Out, Context) +------+
the type of the elements pulled from the upstream along with the Context
the type of the elements that are pushed by the joined Flow along with the Context. This then gets wrapped with a Try and pushed downstream with a Context
the type of the context that is carried around along with the elements.
A bidi GraphStageLogic that is used by TimeoutOrdered and Timeout to wrap flows to add timeout functionality.
A bidi GraphStageLogic that is used by TimeoutOrdered and Timeout to wrap flows to add timeout functionality.
Once an element is pushed from the wrapped flow (from fromWrapped), it first checks if the element is already timed out. If a timeout message has already been sent for that element to downstream, then the element from the wrapped flow is dropped.
A timer gets scheduled when there is a downstream demand that's not immediately addressed. This is to make sure that a timeout response is sent to the downstream when upstream cannot address the demand on time.
Timer precision is at best 10ms to avoid unnecessary timer scheduling cycles
+------+ In ~> | | ~> In | bidi | Out <~ | | <~ FromWrapped +------+
the type of the elements that gets forwarded to the wrapped flow
the type of the elements that the wrapped flow sends back
the type of the elements that are pushed to downstream
A bidi GraphStage that is joined with flows to add timeout functionality.
A bidi GraphStage that is joined with flows to add timeout functionality. This bidi stage is used with flows that guarantee the message ordering.
Emits when an element is available from the wrapped flow or an element has already timed out
Backpressures when the downstream backpressures
Completes when upstream completes
Cancels when downstream cancels
+------+ In ~> | | ~> In | bidi | Try[Out] <~ | | <~ Out +------+
the type of the elements pulled from the upstream and pushed down to joined flow
the type of the elements that are pushed to downstream
Timeout functionality requires each element to be uniquely identified, so it requires a Context, of any type defined by the application, to be carried along with the flow's input and output as a Tuple2 (Scala) or Pair (Java).
Timeout functionality requires each element to be uniquely identified, so it requires a Context, of any type defined by the application, to be carried along with the flow's input and output as a Tuple2 (Scala) or Pair (Java). The requirement is that either the Context itself or a mapping from Context should be able to uniquely identify an element. Here is the ways how a unique id can be retrieved:
uniqueIdMapper
the type of the elements pulled from the upstream along with the Context
the type of the elements that are pushed to downstream along with the Context
the type of the context that is carried around along with the elements.
a BidiFlow with timeout functionality
Orders the stream within a sliding window of maxBounded elements. Each element passing through the BoundedOrdering has an id. The elements can be ordered by the ordering function and the next expected id can be derived from the current id.
It takes an element and emits downstream if the getId(elem) matches the currently stored id, if not enqueues to a priority queue. When an element is emitted, the stored id is updated by calling nextId to match the next expected element and an element is dequeued from the priority queue and emitted if it matches the updated id. If the out-of-order element arrives at a later point than maxBounded then it is emitted straight downstream.
The input and output type of this stream component.
The type of the element's id. Emits when getId(elem) matches the current state, if not enqueues it to priority queue Backpressures when downstream backpressures Completes when upstream completes Cancels when downstream cancels