9bc01ae265
The idea is to filter the sources, replacing @<var>@ occurrences with the mapping for <var> (which is currently hard-coded). @@ -> @. In order to make this work, I had to move the doc sources one directory down (into akka-docs/rst) so that the filtered result could be in a sibling directory so that relative links (to _sphinx plugins or real code) would continue to work. While I was at it I also changed it so that WARNINGs and ERRORs are not swallowed into the debug dump anymore but printed at [warn] level (minimum). One piece of fallout is that the (online) html build is now run after the normal one, not in parallel.
69 lines
3.6 KiB
ReStructuredText
69 lines
3.6 KiB
ReStructuredText
.. _remoting:
|
|
|
|
Location Transparency
|
|
=====================
|
|
|
|
The previous section describes how actor paths are used to enable location
|
|
transparency. This special feature deserves some extra explanation, because the
|
|
related term “transparent remoting” was used quite differently in the context
|
|
of programming languages, platforms and technologies.
|
|
|
|
Distributed by Default
|
|
----------------------
|
|
|
|
Everything in Akka is designed to work in a distributed setting: all
|
|
interactions of actors use purely message passing and everything is
|
|
asynchronous. This effort has been undertaken to ensure that all functions are
|
|
available equally when running within a single JVM or on a cluster of hundreds
|
|
of machines. The key for enabling this is to go from remote to local by way of
|
|
optimization instead of trying to go from local to remote by way of
|
|
generalization. See `this classic paper
|
|
<http://labs.oracle.com/techrep/1994/abstract-29.html>`_ for a detailed
|
|
discussion on why the second approach is bound to fail.
|
|
|
|
Ways in which Transparency is Broken
|
|
------------------------------------
|
|
|
|
What is true of Akka need not be true of the application which uses it, since
|
|
designing for distributed execution poses some restrictions on what is
|
|
possible. The most obvious one is that all messages sent over the wire must be
|
|
serializable. While being a little less obvious this includes closures which
|
|
are used as actor factories (i.e. within :class:`Props`) if the actor is to be
|
|
created on a remote node.
|
|
|
|
Another consequence is that everything needs to be aware of all interactions
|
|
being fully asynchronous, which in a computer network might mean that it may
|
|
take several minutes for a message to reach its recipient (depending on
|
|
configuration). It also means that the probability for a message to be lost is
|
|
much higher than within one JVM, where it is close to zero (still: no hard
|
|
guarantee!).
|
|
|
|
How is Remoting Used?
|
|
---------------------
|
|
|
|
We took the idea of transparency to the limit in that there is nearly no API
|
|
for the remoting layer of Akka: it is purely driven by configuration. Just
|
|
write your application according to the principles outlined in the previous
|
|
sections, then specify remote deployment of actor sub-trees in the
|
|
configuration file. This way, your application can be scaled out without having
|
|
to touch the code. The only piece of the API which allows programmatic
|
|
influence on remote deployment is that :class:`Props` contain a field which may
|
|
be set to a specific :class:`Deploy` instance; this has the same effect as
|
|
putting an equivalent deployment into the configuration file (if both are
|
|
given, configuration file wins).
|
|
|
|
Marking Points for Scaling Up with Routers
|
|
------------------------------------------
|
|
|
|
In addition to being able to run different parts of an actor system on
|
|
different nodes of a cluster, it is also possible to scale up onto more cores
|
|
by multiplying actor sub-trees which support parallelization (think for example
|
|
a search engine processing different queries in parallel). The clones can then
|
|
be routed to in different fashions, e.g. round-robin. The only thing necessary
|
|
to achieve this is that the developer needs to declare a certain actor as
|
|
“withRouter”, then—in its stead—a router actor will be created which will spawn
|
|
up a configurable number of children of the desired type and route to them in
|
|
the configured fashion. Once such a router has been declared, its configuration
|
|
can be freely overridden from the configuration file, including mixing it with
|
|
the remote deployment of (some of) the children. Read more about
|
|
this in :ref:`routing-scala` and :ref:`routing-java`.
|