Represents a callback that should be called asynchronously with the result of a computation.
Coeval
represents lazy computations that can execute synchronously.
Coeval
represents lazy computations that can execute synchronously.
Word definition and origin:
Coeval
is the dual of an expression that evaluates to an A
.There are three evaluation strategies:
The Once
and Always
are both lazy strategies while
Now
and Error
are eager. Once
and Always
are
distinguished from each other only by memoization: once evaluated
Once
will save the value to be returned immediately if it is
needed again. Always
will run its computation every time.
Both Now
and Error
are represented by the
Attempt trait, a sub-type of Coeval
that can be used as a replacement for Scala's own Try
type.
Coeval
supports stack-safe lazy computation via the .map and .flatMap
methods, which use an internal trampoline to avoid stack overflows.
Computation done within .map and .flatMap is always done lazily,
even when applied to a Now
instance.
A mutable location, that is either empty or contains
a value of type A
.
A mutable location, that is either empty or contains
a value of type A
.
It has 2 fundamental atomic operations:
The MVar
is appropriate for building synchronization
primitives and performing simple inter-thread communications.
If it helps, it's similar with a BlockingQueue(capacity = 1)
,
except that it doesn't block any threads, all waiting being
done asynchronously by means of Task.
Given its asynchronous, non-blocking nature, it can be used on top of Javascript as well.
Inspired by Control.Concurrent.MVar
from Haskell and
by scalaz.concurrent.MVar
.
Task
represents a specification for a possibly lazy or
asynchronous computation, which when executed will produce an A
as a result, along with possible side-effects.
Task
represents a specification for a possibly lazy or
asynchronous computation, which when executed will produce an A
as a result, along with possible side-effects.
Compared with Future
from Scala's standard library, Task
does
not represent a running computation or a value detached from time,
as Task
does not execute anything when working with its builders
or operators and it does not submit any work into any thread-pool,
the execution eventually taking place only after runAsync
is
called and not before that.
Note that Task
is conservative in how it spawns logical threads.
Transformations like map
and flatMap
for example will default
to being executed on the logical thread on which the asynchronous
computation was started. But one shouldn't make assumptions about
how things will end up executed, as ultimately it is the
implementation's job to decide on the best execution model. All
you are guaranteed is asynchronous execution after executing
runAsync
.
Safe App
type that runs a Task action.
Safe App
type that runs a Task action.
Clients should implement run
, runl
, or runc
.
Also available for Scala.js, but without the ability to take arguments and without the blocking in main.
The TaskCircuitBreaker
is used to provide stability and prevent
cascading failures in distributed systems.
The TaskCircuitBreaker
is used to provide stability and prevent
cascading failures in distributed systems.
As an example, we have a web application interacting with a remote third party web service. Let's say the third party has oversold their capacity and their database melts down under load. Assume that the database fails in such a way that it takes a very long time to hand back an error to the third party web service. This in turn makes calls fail after a long period of time. Back to our web application, the users have noticed that their form submissions take much longer seeming to hang. Well the users do what they know to do which is use the refresh button, adding more requests to their already running requests. This eventually causes the failure of the web application due to resource exhaustion. This will affect all users, even those who are not using functionality dependent on this third party web service.
Introducing circuit breakers on the web service call would cause the requests to begin to fail-fast, letting the user know that something is wrong and that they need not refresh their request. This also confines the failure behavior to only those users that are using functionality dependent on the third party, other users are no longer affected as there is no resource exhaustion. Circuit breakers can also allow savvy developers to mark portions of the site that use the functionality unavailable, or perhaps show some cached content as appropriate while the breaker is open.
The circuit breaker models a concurrent state machine that can be in any of these 3 states:
TaskCircuitBreaker
startsfailures
counterfailures
counter reaches the maxFailures
count,
the breaker is tripped into Open
stateExecutionRejectedException
resetTimeout
, the circuit breaker
enters a HalfOpen state,
allowing one task to go through for testing the connectionOpen
has expired is allowed through
without failing fast, just before the circuit breaker is
evolved into the HalfOpen
stateHalfOpen
fail-fast with an exception
just as in Open stateClosed
state, with the resetTimeout
and the
failures
count also reset to initial valuesOpen
state (the resetTimeout
is multiplied by the
exponential backoff factor)import monix.eval._ import scala.concurrent.duration._ val circuitBreaker = TaskCircuitBreaker( maxFailures = 5, resetTimeout = 10.seconds ) //... val problematic = Task { val nr = util.Random.nextInt() if (nr % 2 == 0) nr else throw new RuntimeException("dummy") } val task = circuitBreaker.protect(problematic)
When attempting to close the circuit breaker and resume normal operations, we can also apply an exponential backoff for repeated failed attempts, like so:
val circuitBreaker = TaskCircuitBreaker( maxFailures = 5, resetTimeout = 10.seconds, exponentialBackoffFactor = 2, maxResetTimeout = 10.minutes )
In this sample we attempt to reconnect after 10 seconds, then after 20, 40 and so on, a delay that keeps increasing up to a configurable maximum of 10 minutes.
This Monix data type was inspired by the availability of Akka's Circuit Breaker.
The TaskSemaphore
is an asynchronous semaphore implementation that
limits the parallelism on task execution.
The TaskSemaphore
is an asynchronous semaphore implementation that
limits the parallelism on task execution.
The following example instantiates a semaphore with a maximum parallelism of 10:
val semaphore = TaskSemaphore(maxParallelism = 10) def makeRequest(r: HttpRequest): Task[HttpResponse] = ??? // For such a task no more than 10 requests // are allowed to be executed in parallel. val task = semaphore.greenLight(makeRequest(???))
Represents a callback that should be called asynchronously with the result of a computation. Used by Task to signal the completion of asynchronous computations on
runAsync
.The
onSuccess
method should be called only once, with the successful result, whereasonError
should be called if the result is an error.