Completes::await()
or Future::get()
, which are blocking operations. If these are used by your actors, throughput will be stopped for as long as the blocking operation requires to finish. Note that both forms of Completes::await()
are meant to be used for tests only, and it is only the test case that should use either form of Completes::await()
. Never use this in a production environment.Scheduler
instances.this
outside. For example, it is a bug to pass this
to the Scheduler
or to some service actor that our actor depends on. It will work because whatever protocol, such as SomeProtocol
, the actor implements, will be provided by passing this
to obtain a service. But that's wrong and a sure way to experience races. You should always pass selfAs(SomeProtocol.class)
as a parameter to the Scheduler
or another actor.Completes<T>
expression evaluating inside your actor that mutates state at the same time that a separate assigned thread is delivering a message that mutates state. Some overlook the fact that Completes<T>
delivers asynchronous outcomes via a pooled actor designed for that purpose. This means that a separate thread may be entering your actor because you have invited it in with the Completes<T>
outcome. You can solve this problem in one of two ways:Completes<T>
from inside an actor. Design collaborating actors to accept dependents as expected protocols. For example, SomeProtocol
provides a service message (method) that takes a SomeProtocolInterest
as a parameter. When the actor handling the SomeProtocol
message delivery has finished, it replies to its dependent using SomeProtocolInterest
. Of course the dependent actor implements the SomeProtocolInterest
interface, and passes a reference using selfAs(SomeProtocolInterest.class)
.Completes<T>
inside your actor, and admittedly this may be necessary given the design of some protocols, never modify your actor's state from a Completes<T>
outcome handler, such as andThen(function)
. Rather, send yourself a message that will be handled with exclusive access to your state. We suggest not exposing the protocol used for this purpose outside your actor and document the protocol as being for internal use only. As an example, your actor may implement MyInternalProtocol
(by a different name) and the Completes<T>
outcome pipeline handler dispatches to one of its messages (methods) such as: selfAs(MyInternalProtocol.class).accept(someOutcomeData)
.Scheduler
in XOOM Actors is used for timers that schedule one or continuous future signals to an actor. The XOOM Actors term used for delivering messages to actors on threads is called dispatching. The Erlang BEAM uses the term scheduler and scheduling to describe how time slices are used to managed processes (a.k.a actors).