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.
thisoutside. For example, it is a bug to pass
Scheduleror 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
thisto 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
Scheduleror 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,
SomeProtocolprovides a service message (method) that takes a
SomeProtocolInterestas a parameter. When the actor handling the
SomeProtocolmessage delivery has finished, it replies to its dependent using
SomeProtocolInterest. Of course the dependent actor implements the
SomeProtocolInterestinterface, and passes a reference using
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:
Schedulerin 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).