Backpressure protocols ensure that fast producers do not overwhelm consumers.
Backpressure protocols ensure that fast producers do not overwhelm consumers.
In an asynchronous system, there is always a possibility that a producer reactor sends more events than the consumer can handle. This can eventually blow up the memory requirements of the consumer, since its event queue grows indefinitely. Backpressure links ensure that the
Backpressure is parametric in the choice of the underlying communication medium.
A backpressure link is established on top of a two-way link,
but that two-way links may be non-reliable or reliable. This is abstracted
away in a configuration object called a Medium
, which is necessary to start
the backpressure protocol.
Utilities that manipulate and transform channels.
Contains various convenience operations.
Utilities that convert values of different types to events streams.
General communication patterns.
General communication patterns.
Allows specifying communication patterns in a generic way.
As an example, one can declaratively retry server requests until a timeout, by sending a throttled sequence of requests until a timeout, and taking the first reply that comes:
Seq(1, 2, 4).toEvents.throttle(x => x.seconds).map(_ => server ? "req") .first.until(timeout(3.seconds))
Represents a connected reliable channel.
Represents a connected reliable channel.
When using a reliable channel to send events, clients have some level of guarantee
that their events will not be impaired in some way. The exact guarantees are
detailed in the Policy
object which must be specified when establishing a
reliable link.
To close this reliable link, clients must use the associated subscription.
type of the events sent by this reliable channel
channel underlying the reliable link
subscription associated with the reliable link
Reliable communication protocols ensure reliable delivery.
Reliable communication protocols ensure reliable delivery.
Reliable delivery is normally ensured when delivering events between reactors in the same reactor system. However, when the underlying transport is an unreliable network, events may be delayed, lost, duplicated or arbitrarily corrupted, depending on the properties of the communication medium.
Reliability protocols ensure that all original events are delivered exactly once and in order, using either one-way or two-way reliable links.
Communication patterns for routing.
A server channel accepts tuples with the request event and channel to reply on.
A server channel accepts tuples with the request event and channel to reply on.
Communication patterns based on request-reply.
Represents a stamped object.
Methods that convert collections to event streams.
Methods that convert collections to event streams.
Since standard collections are not specialized, boxing is potentially possible.
Represents the state of an established 2-way channel.
Represents the state of an established 2-way channel.
To close the 2-way channel, use the associated Subscription
object.
type of the incoming events
type of the outgoing events
the output channel, for outgoing events
the input event stream, for incoming events
subscription associated with this 2-way link
Utility methods for frequently used delay sequences.
Utility methods for frequently used delay sequences.
Contains types and factory functions for router protocols.
Contains various options for tuning the server protocol.
Contains various options for tuning the server protocol.
Adds convenience methods for reactor systems.
Adds convenience methods for reactor systems.
Retry the specified request with a backoff scheme.
Retry the specified request with a backoff scheme.
After a stream from one of the requests starts emitting events, all the other requests are unsubscribed from, and not further retrying takes place.
To create different backoff schemes, see the Backoff
object.
the duration of subsequent delays between requests
the code that creates the request and a stream of replies
the stream of replies that was first to emit an event
Retry the specified request a fixed number of times.
Retry the specified request a fixed number of times.
the number of times to retry the request
the delay between each request
the code that creates the request and a stream of replies
the stream of replies that was first to emit an event