Updated documentation to reflect changes in remoting
This commit is contained in:
Endre Sándor Varga
parent
a31d98340f
commit
c4abbd95bd
11 changed files with 219 additions and 91 deletions
|
|
@ -604,7 +604,7 @@ From JMX you can:
|
|||
* mark any node in the cluster as down
|
||||
* tell any node in the cluster to leave
|
||||
|
||||
Member nodes are identified with their address, in format `akka://actor-system-name@hostname:port`.
|
||||
Member nodes are identified by their address, in format `akka.<protocol>://<actor-system-name>@<hostname>:<port>`.
|
||||
|
||||
.. _cluster_command_line_java:
|
||||
|
||||
|
|
@ -632,10 +632,10 @@ Run it without parameters to see instructions about how to use the script::
|
|||
node cluster)
|
||||
is-available - Checks if the member node is available
|
||||
Where the <node-url> should be on the format of
|
||||
'akka://actor-system-name@hostname:port'
|
||||
'akka.<protocol>://<actor-system-name>@<hostname>:<port>'
|
||||
|
||||
Examples: bin/akka-cluster localhost:9999 is-available
|
||||
bin/akka-cluster localhost:9999 join akka://MySystem@darkstar:2552
|
||||
bin/akka-cluster localhost:9999 join akka.tcp://MySystem@darkstar:2552
|
||||
bin/akka-cluster localhost:9999 cluster-status
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -609,7 +609,7 @@ From JMX you can:
|
|||
* mark any node in the cluster as down
|
||||
* tell any node in the cluster to leave
|
||||
|
||||
Member nodes are identified with their address, in format `akka://actor-system-name@hostname:port`.
|
||||
Member nodes are identified by their address, in format `akka.<protocol>://<actor-system-name>@<hostname>:<port>`.
|
||||
|
||||
.. _cluster_command_line_scala:
|
||||
|
||||
|
|
@ -637,10 +637,10 @@ Run it without parameters to see instructions about how to use the script::
|
|||
node cluster)
|
||||
is-available - Checks if the member node is available
|
||||
Where the <node-url> should be on the format of
|
||||
'akka://actor-system-name@hostname:port'
|
||||
'akka.<protocol>://<actor-system-name>@<hostname>:<port>'
|
||||
|
||||
Examples: bin/akka-cluster localhost:9999 is-available
|
||||
bin/akka-cluster localhost:9999 join akka://MySystem@darkstar:2552
|
||||
bin/akka-cluster localhost:9999 join akka.tcp://MySystem@darkstar:2552
|
||||
bin/akka-cluster localhost:9999 cluster-status
|
||||
|
||||
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 41 KiB After Width: | Height: | Size: 42 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 56 KiB After Width: | Height: | Size: 42 KiB |
|
|
@ -98,14 +98,14 @@ Each actor path has an address component, describing the protocol and location
|
|||
by which the corresponding actor is reachable, followed by the names of the
|
||||
actors in the hierarchy from the root up. Examples are::
|
||||
|
||||
"akka://my-sys/user/service-a/worker1" // purely local
|
||||
"akka://my-sys@host.example.com:5678/user/service-b" // local or remote
|
||||
"cluster://my-cluster/service-c" // clustered (Future Extension)
|
||||
"akka://my-sys/user/service-a/worker1" // purely local
|
||||
"akka.tcp://my-sys@host.example.com:5678/user/service-b" // remote
|
||||
"cluster://my-cluster/service-c" // clustered (Future Extension)
|
||||
|
||||
Here, ``akka`` is the default remote protocol for the 2.0 release, and others
|
||||
are pluggable. The interpretation of the host and port part (i.e.
|
||||
``serv.example.com:5678`` in the example) depends on the transport mechanism
|
||||
used, but it must abide by the URI structural rules.
|
||||
Here, ``akka.tcp`` is the default remote transport for the 2.2 release; other transports
|
||||
are pluggable. A remote host using UDP would be accessible by using ``akka.udp``.
|
||||
The interpretation of the host and port part (i.e.``serv.example.com:5678`` in the example)
|
||||
depends on the transport mechanism used, but it must abide by the URI structural rules.
|
||||
|
||||
Logical Actor Paths
|
||||
^^^^^^^^^^^^^^^^^^^
|
||||
|
|
|
|||
|
|
@ -44,8 +44,8 @@ public class RemoteDeploymentDocTestBase {
|
|||
@Test
|
||||
public void demonstrateDeployment() {
|
||||
//#make-address
|
||||
Address addr = new Address("akka", "sys", "host", 1234);
|
||||
addr = AddressFromURIString.parse("akka://sys@host:1234"); // the same
|
||||
Address addr = new Address("akka.tcp", "sys", "host", 1234);
|
||||
addr = AddressFromURIString.parse("akka.tcp://sys@host:1234"); // the same
|
||||
//#make-address
|
||||
//#deploy
|
||||
ActorRef ref = system.actorOf(new Props(SampleActor.class).withDeploy(
|
||||
|
|
@ -66,7 +66,7 @@ public class RemoteDeploymentDocTestBase {
|
|||
@Test
|
||||
public void demonstrateProgrammaticConfig() {
|
||||
//#programmatic
|
||||
ConfigFactory.parseString("akka.remote.netty.hostname=\"1.2.3.4\"")
|
||||
ConfigFactory.parseString("akka.remote.netty.tcp.hostname=\"1.2.3.4\"")
|
||||
.withFallback(ConfigFactory.load());
|
||||
//#programmatic
|
||||
}
|
||||
|
|
|
|||
|
|
@ -25,8 +25,8 @@ to your ``application.conf`` file::
|
|||
provider = "akka.remote.RemoteActorRefProvider"
|
||||
}
|
||||
remote {
|
||||
transport = "akka.remote.netty.NettyRemoteTransport"
|
||||
netty {
|
||||
enabled-transports = ["akka.remote.netty.tcp"]
|
||||
netty.tcp {
|
||||
hostname = "127.0.0.1"
|
||||
port = 2552
|
||||
}
|
||||
|
|
@ -72,11 +72,11 @@ Looking up Remote Actors
|
|||
|
||||
``actorFor(path)`` will obtain an ``ActorRef`` to an Actor on a remote node::
|
||||
|
||||
ActorRef actor = context.actorFor("akka://app@10.0.0.1:2552/user/serviceA/worker");
|
||||
ActorRef actor = context.actorFor("akka.tcp://app@10.0.0.1:2552/user/serviceA/worker");
|
||||
|
||||
As you can see from the example above the following pattern is used to find an ``ActorRef`` on a remote node::
|
||||
|
||||
akka://<actorsystemname>@<hostname>:<port>/<actor path>
|
||||
akka.<protocol>://<actorsystemname>@<hostname>:<port>/<actor path>
|
||||
|
||||
Once you obtained a reference to the actor you can interact with it they same way you would with a local actor, e.g.::
|
||||
|
||||
|
|
@ -96,7 +96,7 @@ If you want to use the creation functionality in Akka remoting you have to furth
|
|||
actor {
|
||||
deployment {
|
||||
/sampleActor {
|
||||
remote = "akka://sampleActorSystem@127.0.0.1:2553"
|
||||
remote = "akka.tcp://sampleActorSystem@127.0.0.1:2553"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -187,7 +187,7 @@ This is also done via configuration::
|
|||
router = "round-robin"
|
||||
nr-of-instances = 10
|
||||
target {
|
||||
nodes = ["akka://app@10.0.0.2:2552", "akka://app@10.0.0.3:2552"]
|
||||
nodes = ["akka.tcp://app@10.0.0.2:2552", "akka://app@10.0.0.3:2552"]
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -302,6 +302,59 @@ Observe how the name of the server actor matches the deployment given in the
|
|||
configuration file, which will transparently delegate the actor creation to the
|
||||
remote node.
|
||||
|
||||
Pluggable transport support
|
||||
---------------------------
|
||||
|
||||
Akka can be configured to use various transports to communicate with remote systems. The core
|
||||
component of this feature is the :meth:`akka.remote.Transport` SPI. Transport implementations must extend this trait.
|
||||
Transports can be loaded by setting the ``akka.remote.enabled-transports`` configuration key to point to one or
|
||||
more configuration sections containing driver descriptions.
|
||||
|
||||
An example of setting up the default Netty based SSL driver as default::
|
||||
|
||||
akka {
|
||||
remote {
|
||||
enabled-transports = [akka.remote.netty.ssl]
|
||||
|
||||
netty.ssl {
|
||||
key-store = "mykeystore"
|
||||
trust-store = "mytruststore"
|
||||
key-store-password = "changeme"
|
||||
trust-store-password = "changeme"
|
||||
protocol = "TLSv1"
|
||||
random-number-generator = "AES128CounterSecureRNG"
|
||||
enabled-algorithms = [TLS_RSA_WITH_AES_128_CBC_SHA]
|
||||
sha1prng-random-source = "/dev/./urandom"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
An example of setting up a custom transport implementation::
|
||||
|
||||
akka {
|
||||
remote {
|
||||
applied-transports = ["akka.remote.mytransport"]
|
||||
|
||||
mytransport {
|
||||
# The transport-class configuration entry is required, and
|
||||
# it must contain the fully qualified name of the transport
|
||||
# implementation
|
||||
transport-class = "my.package.MyTransport"
|
||||
|
||||
# It is possible to decorate Transports with additional services.
|
||||
# Adapters should be registered in the "adapters" sections to
|
||||
# be able to apply them to transports
|
||||
applied-adapters = []
|
||||
|
||||
# Driver specific configuration options has to be in the same
|
||||
# section:
|
||||
some-config = foo
|
||||
another-config = bar
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
Remote Events
|
||||
-------------
|
||||
|
||||
|
|
@ -309,9 +362,13 @@ It is possible to listen to events that occur in Akka Remote, and to subscribe/u
|
|||
you simply register as listener to the below described types in on the ``ActorSystem.eventStream``.
|
||||
|
||||
.. note::
|
||||
To subscribe to any outbound-related events, subscribe to ``RemoteClientLifeCycleEvent``
|
||||
To subscribe to any inbound-related events, subscribe to ``RemoteServerLifeCycleEvent``
|
||||
To subscribe to any remote events, subscribe to ``RemoteLifeCycleEvent``
|
||||
To subscribe to any remote event, subscribe to :meth:``RemotingLifecycleEvent`
|
||||
To subscribe to events related only to the lifecycle of associations, subscribe to :meth:`akka.remote.AssociationEvent`
|
||||
|
||||
.. note::
|
||||
The use of term "Association" instead of "Connection" reflects that the remoting subsystem may use
|
||||
connectionless transports, but an association similar to transport layer connections is maintained between endpoints
|
||||
by the Akka protocol.
|
||||
|
||||
By default an event listener is registered which logs all of the events
|
||||
described below. This default was chosen to help setting up a system, but it is
|
||||
|
|
@ -323,35 +380,22 @@ finished.
|
|||
``akka.remote.log-remote-lifecycle-events = off`` in your
|
||||
``application.conf``.
|
||||
|
||||
To intercept when an outbound connection is disconnected, you listen to ``RemoteClientDisconnected`` which
|
||||
holds the transport used (RemoteTransport) and the outbound address that was disconnected (Address).
|
||||
To be notified when an association is over ("disconnected") listen to ``DisassociatedEvent`` which
|
||||
holds the direction of the association (inbound or outbound) and the addresses of the involved parties.
|
||||
|
||||
To intercept when an outbound connection is connected, you listen to ``RemoteClientConnected`` which
|
||||
holds the transport used (RemoteTransport) and the outbound address that was connected to (Address).
|
||||
To be notified when an association is successfully established ("connected") listen to ``AssociatedEvent`` which
|
||||
holds the direction of the association (inbound or outbound) and the addresses of the involved parties.
|
||||
|
||||
To intercept when an outbound client is started you listen to ``RemoteClientStarted``
|
||||
which holds the transport used (RemoteTransport) and the outbound address that it is connected to (Address).
|
||||
To intercept errors directly related to associations, listen to ``AssociationErrorEvent`` which
|
||||
holds the direction of the association (inbound or outbound), the addresses of the involved parties and the
|
||||
``Throwable`` cause.
|
||||
|
||||
To intercept when an outbound client is shut down you listen to ``RemoteClientShutdown``
|
||||
which holds the transport used (RemoteTransport) and the outbound address that it was connected to (Address).
|
||||
To be notified when the remoting subsystem is ready to accept associations, listen to ``RemotingListenEvent`` which
|
||||
contains the addresses the remoting listens on.
|
||||
|
||||
For general outbound-related errors, that do not classify as any of the others, you can listen to ``RemoteClientError``,
|
||||
which holds the cause (Throwable), the transport used (RemoteTransport) and the outbound address (Address).
|
||||
To be notified when the remoting subsystem has been shut down, listen to ``RemotingShutdownEvent``.
|
||||
|
||||
To intercept when an inbound server is started (typically only once) you listen to ``RemoteServerStarted``
|
||||
which holds the transport that it will use (RemoteTransport).
|
||||
|
||||
To intercept when an inbound server is shut down (typically only once) you listen to ``RemoteServerShutdown``
|
||||
which holds the transport that it used (RemoteTransport).
|
||||
|
||||
To intercept when an inbound connection has been established you listen to ``RemoteServerClientConnected``
|
||||
which holds the transport used (RemoteTransport) and optionally the address that connected (Option<Address>).
|
||||
|
||||
To intercept when an inbound connection has been disconnected you listen to ``RemoteServerClientDisconnected``
|
||||
which holds the transport used (RemoteTransport) and optionally the address that disconnected (Option<Address>).
|
||||
|
||||
To intercept when an inbound remote client has been closed you listen to ``RemoteServerClientClosed``
|
||||
which holds the transport used (RemoteTransport) and optionally the address of the remote client that was closed (Option<Address>).
|
||||
To intercept generic remoting related errors, listen to ``RemotingErrorEvent`` which holds the ``Throwable`` cause.
|
||||
|
||||
Remote Security
|
||||
^^^^^^^^^^^^^^^
|
||||
|
|
@ -418,7 +462,7 @@ as the ``require-cookie`` option turned on.
|
|||
|
||||
Here is an example config::
|
||||
|
||||
akka.remote.netty {
|
||||
akka.remote {
|
||||
secure-cookie = "090A030E0F0A05010900000A0C0E0C0B03050D05"
|
||||
require-cookie = on
|
||||
}
|
||||
|
|
@ -426,8 +470,9 @@ Here is an example config::
|
|||
SSL
|
||||
---
|
||||
|
||||
SSL can be used for the remote transport by activating the ``akka.remote.netty.ssl``
|
||||
configuration section. See description of the settings in the :ref:`remoting-java-configuration`.
|
||||
SSL can be used as the remote transport by adding ``akka.remote.netty.ssl``
|
||||
to the ``enabled-transport`` configuration section. See a description of the settings
|
||||
in the :ref:`remoting-java-configuration` section.
|
||||
|
||||
The SSL support is implemented with Java Secure Socket Extension, please consult the offical
|
||||
`Java Secure Socket Extension documentation <http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html>`_
|
||||
|
|
|
|||
|
|
@ -270,7 +270,7 @@ its identity (i.e. the path which was looked up).
|
|||
|
||||
Remote actor addresses may also be looked up, if remoting is enabled::
|
||||
|
||||
getContext().actorFor("akka://app@otherhost:1234/user/serviceB")
|
||||
getContext().actorFor("akka.tcp://app@otherhost:1234/user/serviceB")
|
||||
|
||||
These look-ups return a (possibly remote) actor reference immediately, so you
|
||||
will have to send to it and await a reply in order to verify that ``serviceB``
|
||||
|
|
|
|||
|
|
@ -112,3 +112,42 @@ The SLF4J logger has been renamed from ``akka.event.slf4j.Slf4jEventHandler`` to
|
|||
|
||||
The ``java.util.logging`` logger has been renamed from ``akka.contrib.jul.JavaLoggingEventHandler`` to
|
||||
``akka.contrib.jul.JavaLogger``.
|
||||
|
||||
Remoting
|
||||
========
|
||||
|
||||
The remoting subsystem of Akka has been replaced in favor of a more flexible, pluggable driver based implementation. This
|
||||
has required some changes to the configuration sections of ``akka.remote``, the format of Akka remote addresses
|
||||
and the Akka protocol itself.
|
||||
|
||||
The internal communication protocol of Akka has been evolved into a completely standalone entity, not tied to any
|
||||
particular transport. This change has the effect that Akka 2.2 remoting is no longer able to directly communicate with
|
||||
older versions.
|
||||
|
||||
The ``akka.remote.transport`` configuration key has been removed as the remoting system itself is no longer replaceable.
|
||||
Custom transports are now pluggable via the ``akka.remote.enabled-transpotrs`` key (see the :meth:`akka.remote.Transport` SPI
|
||||
and the documentation of remoting for more detail on drivers). The transport loaded by default is a Netty based TCP
|
||||
driver similar in functionality to the default remoting in Akka 2.1.
|
||||
|
||||
Transports are now fully pluggable through drivers, therefore transport specific settings like listening ports now live in the namespace
|
||||
of their driver configuration. In particular TCP related settings are now under ``akka.remote.netty.tcp``.
|
||||
|
||||
As a result of being able to replace the transport protocol, it is now necessary to include the protocol information
|
||||
in Akka URLs for remote addresses. Therefore a remote address of ``akka://remote-sys@remotehost:2552/user/actor``
|
||||
has to be changed to ``akka.tcp://remote-sys@remotehost:2552/user/actor`` if the remote system uses TCP as transport. If
|
||||
the other system uses SSL on top of TCP, the correct address would be ``akka.ssl.tcp://remote-sys@remotehost:2552/user/actor``.
|
||||
|
||||
Remote lifecycle events have been changed to a more coarse-grained, simplified model. All remoting events are subclasses
|
||||
of :meth:`akka.remote.RemotingLifecycle`. Events related to the lifecycle of *associations* (formerly called *connections*)
|
||||
be it inbound or outbound are subclasses of :meth:`akka.remote.AssociationEvent` (which is in turn a subclass of
|
||||
:meth:`RemotingLifecycle`). The direction of the association (inbound or outbound) triggering an ``AssociationEvent`` is
|
||||
available via the ``inbound`` boolean field of the event.
|
||||
|
||||
.. note::
|
||||
The change in terminology from "Connection" to "Association" reflects the fact that the remoting subsystem may use
|
||||
connectionless transports, but an association similar to transport layer connections is maintained between endpoints
|
||||
by the Akka protocol.
|
||||
|
||||
New configuration settings are also available, see the remoting documentation for more detail: :ref:`remoting-scala`
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -381,7 +381,7 @@ its identity (i.e. the path which was looked up).
|
|||
|
||||
Remote actor addresses may also be looked up, if remoting is enabled::
|
||||
|
||||
context.actorFor("akka://app@otherhost:1234/user/serviceB")
|
||||
context.actorFor("akka.tcp://app@otherhost:1234/user/serviceB")
|
||||
|
||||
These look-ups return a (possibly remote) actor reference immediately, so you
|
||||
will have to send to it and await a reply in order to verify that ``serviceB``
|
||||
|
|
|
|||
|
|
@ -22,8 +22,8 @@ to your ``application.conf`` file::
|
|||
provider = "akka.remote.RemoteActorRefProvider"
|
||||
}
|
||||
remote {
|
||||
transport = "akka.remote.netty.NettyRemoteTransport"
|
||||
netty {
|
||||
enabled-transports = ["akka.remote.netty.tcp"]
|
||||
netty.tcp {
|
||||
hostname = "127.0.0.1"
|
||||
port = 2552
|
||||
}
|
||||
|
|
@ -42,7 +42,7 @@ As you can see in the example above there are four things you need to add to get
|
|||
|
||||
.. note::
|
||||
The port number needs to be unique for each actor system on the same machine even if the actor
|
||||
systems have different names. This is because each actor system has its own network subsystem
|
||||
systems have different names. This is because each actor system has its own networking subsystem
|
||||
listening for connections and handling messages as not to interfere with other actor systems.
|
||||
|
||||
.. _remoting-scala-configuration:
|
||||
|
|
@ -79,11 +79,11 @@ Looking up Remote Actors
|
|||
|
||||
``actorFor(path)`` will obtain an ``ActorRef`` to an Actor on a remote node, e.g.::
|
||||
|
||||
val actor = context.actorFor("akka://actorSystemName@10.0.0.1:2552/user/actorName")
|
||||
val actor = context.actorFor("akka.tcp://actorSystemName@10.0.0.1:2552/user/actorName")
|
||||
|
||||
As you can see from the example above the following pattern is used to find an ``ActorRef`` on a remote node::
|
||||
|
||||
akka://<actor system>@<hostname>:<port>/<actor path>
|
||||
akka.<protocol>://<actor system>@<hostname>:<port>/<actor path>
|
||||
|
||||
Once you obtained a reference to the actor you can interact with it they same way you would with a local actor, e.g.::
|
||||
|
||||
|
|
@ -103,7 +103,7 @@ If you want to use the creation functionality in Akka remoting you have to furth
|
|||
actor {
|
||||
deployment {
|
||||
/sampleActor {
|
||||
remote = "akka://sampleActorSystem@127.0.0.1:2553"
|
||||
remote = "akka.tcp://sampleActorSystem@127.0.0.1:2553"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -194,7 +194,7 @@ This is also done via configuration::
|
|||
router = "round-robin"
|
||||
nr-of-instances = 10
|
||||
target {
|
||||
nodes = ["akka://app@10.0.0.2:2552", "akka://app@10.0.0.3:2552"]
|
||||
nodes = ["akka.tcp://app@10.0.0.2:2552", "akka.tcp://app@10.0.0.3:2552"]
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -304,6 +304,58 @@ Observe how the name of the server actor matches the deployment given in the
|
|||
configuration file, which will transparently delegate the actor creation to the
|
||||
remote node.
|
||||
|
||||
Pluggable transport support
|
||||
---------------------------
|
||||
|
||||
Akka can be configured to use various transports to communicate with remote systems. The core
|
||||
component of this feature is the :meth:`akka.remote.Transport` SPI. Transport implementations must extend this trait.
|
||||
Transports can be loaded by setting the ``akka.remote.enabled-transports`` configuration key to point to one or
|
||||
more configuration sections containing driver descriptions.
|
||||
|
||||
An example of setting up the default Netty based SSL driver as default::
|
||||
|
||||
akka {
|
||||
remote {
|
||||
enabled-transports = [akka.remote.netty.ssl]
|
||||
|
||||
netty.ssl {
|
||||
key-store = "mykeystore"
|
||||
trust-store = "mytruststore"
|
||||
key-store-password = "changeme"
|
||||
trust-store-password = "changeme"
|
||||
protocol = "TLSv1"
|
||||
random-number-generator = "AES128CounterSecureRNG"
|
||||
enabled-algorithms = [TLS_RSA_WITH_AES_128_CBC_SHA]
|
||||
sha1prng-random-source = "/dev/./urandom"
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
An example of setting up a custom transport implementation::
|
||||
|
||||
akka {
|
||||
remote {
|
||||
applied-transports = ["akka.remote.mytransport"]
|
||||
|
||||
mytransport {
|
||||
# The transport-class configuration entry is required, and
|
||||
# it must contain the fully qualified name of the transport
|
||||
# implementation
|
||||
transport-class = "my.package.MyTransport"
|
||||
|
||||
# It is possible to decorate Transports with additional services.
|
||||
# Adapters should be registered in the "adapters" sections to
|
||||
# be able to apply them to transports
|
||||
applied-adapters = []
|
||||
|
||||
# Driver specific configuration options has to be in the same
|
||||
# section:
|
||||
some-config = foo
|
||||
another-config = bar
|
||||
}
|
||||
|
||||
|
||||
|
||||
Remote Events
|
||||
-------------
|
||||
|
||||
|
|
@ -311,9 +363,13 @@ It is possible to listen to events that occur in Akka Remote, and to subscribe/u
|
|||
you simply register as listener to the below described types in on the ``ActorSystem.eventStream``.
|
||||
|
||||
.. note::
|
||||
To subscribe to any outbound-related events, subscribe to ``RemoteClientLifeCycleEvent``
|
||||
To subscribe to any inbound-related events, subscribe to ``RemoteServerLifeCycleEvent``
|
||||
To subscribe to any remote events, subscribe to ``RemoteLifeCycleEvent``
|
||||
To subscribe to any remote event, subscribe to :meth:``RemotingLifecycleEvent`
|
||||
To subscribe to events related only to the lifecycle of associations, subscribe to :meth:`akka.remote.AssociationEvent`
|
||||
|
||||
.. note::
|
||||
The use of term "Association" instead of "Connection" reflects that the remoting subsystem may use
|
||||
connectionless transports, but an association similar to transport layer connections is maintained between endpoints
|
||||
by the Akka protocol.
|
||||
|
||||
By default an event listener is registered which logs all of the events
|
||||
described below. This default was chosen to help setting up a system, but it is
|
||||
|
|
@ -325,35 +381,22 @@ finished.
|
|||
``akka.remote.log-remote-lifecycle-events = off`` in your
|
||||
``application.conf``.
|
||||
|
||||
To intercept when an outbound connection is disconnected, you listen to ``RemoteClientDisconnected`` which
|
||||
holds the transport used (RemoteTransport) and the outbound address that was disconnected (Address).
|
||||
To be notified when an association is over ("disconnected") listen to ``DisassociatedEvent`` which
|
||||
holds the direction of the association (inbound or outbound) and the addresses of the involved parties.
|
||||
|
||||
To intercept when an outbound connection is connected, you listen to ``RemoteClientConnected`` which
|
||||
holds the transport used (RemoteTransport) and the outbound address that was connected to (Address).
|
||||
To be notified when an association is successfully established ("connected") listen to ``AssociatedEvent`` which
|
||||
holds the direction of the association (inbound or outbound) and the addresses of the involved parties.
|
||||
|
||||
To intercept when an outbound client is started you listen to ``RemoteClientStarted``
|
||||
which holds the transport used (RemoteTransport) and the outbound address that it is connected to (Address).
|
||||
To intercept errors directly related to associations, listen to ``AssociationErrorEvent`` which
|
||||
holds the direction of the association (inbound or outbound), the addresses of the involved parties and the
|
||||
``Throwable`` cause.
|
||||
|
||||
To intercept when an outbound client is shut down you listen to ``RemoteClientShutdown``
|
||||
which holds the transport used (RemoteTransport) and the outbound address that it was connected to (Address).
|
||||
To be notified when the remoting subsystem is ready to accept associations, listen to ``RemotingListenEvent`` which
|
||||
contains the addresses the remoting listens on.
|
||||
|
||||
For general outbound-related errors, that do not classify as any of the others, you can listen to ``RemoteClientError``,
|
||||
which holds the cause (Throwable), the transport used (RemoteTransport) and the outbound address (Address).
|
||||
To be notified when the remoting subsystem has been shut down, listen to ``RemotingShutdownEvent``.
|
||||
|
||||
To intercept when an inbound server is started (typically only once) you listen to ``RemoteServerStarted``
|
||||
which holds the transport that it will use (RemoteTransport).
|
||||
|
||||
To intercept when an inbound server is shut down (typically only once) you listen to ``RemoteServerShutdown``
|
||||
which holds the transport that it used (RemoteTransport).
|
||||
|
||||
To intercept when an inbound connection has been established you listen to ``RemoteServerClientConnected``
|
||||
which holds the transport used (RemoteTransport) and optionally the address that connected (Option[Address]).
|
||||
|
||||
To intercept when an inbound connection has been disconnected you listen to ``RemoteServerClientDisconnected``
|
||||
which holds the transport used (RemoteTransport) and optionally the address that disconnected (Option[Address]).
|
||||
|
||||
To intercept when an inbound remote client has been closed you listen to ``RemoteServerClientClosed``
|
||||
which holds the transport used (RemoteTransport) and optionally the address of the remote client that was closed (Option[Address]).
|
||||
To intercept generic remoting related errors, listen to ``RemotingErrorEvent`` which holds the ``Throwable`` cause.
|
||||
|
||||
Remote Security
|
||||
^^^^^^^^^^^^^^^
|
||||
|
|
@ -420,7 +463,7 @@ as the ``require-cookie`` option turned on.
|
|||
|
||||
Here is an example config::
|
||||
|
||||
akka.remote.netty {
|
||||
akka.remote {
|
||||
secure-cookie = "090A030E0F0A05010900000A0C0E0C0B03050D05"
|
||||
require-cookie = on
|
||||
}
|
||||
|
|
@ -428,8 +471,9 @@ Here is an example config::
|
|||
SSL
|
||||
---
|
||||
|
||||
SSL can be used for the remote transport by activating the ``akka.remote.netty.ssl``
|
||||
configuration section. See description of the settings in the :ref:`remoting-scala-configuration`.
|
||||
SSL can be used as the remote transport by adding ``akka.remote.netty.ssl``
|
||||
to the ``enabled-transport`` configuration section. See a description of the settings
|
||||
in the :ref:`remoting-scala-configuration` section.
|
||||
|
||||
The SSL support is implemented with Java Secure Socket Extension, please consult the offical
|
||||
`Java Secure Socket Extension documentation <http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html>`_
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue