diff --git a/akka-docs/rst/cluster/cluster-usage-java.rst b/akka-docs/rst/cluster/cluster-usage-java.rst index b9b23b0163..8f08dbaa7e 100644 --- a/akka-docs/rst/cluster/cluster-usage-java.rst +++ b/akka-docs/rst/cluster/cluster-usage-java.rst @@ -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.://@:`. .. _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 should be on the format of - 'akka://actor-system-name@hostname:port' + 'akka.://@:' 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 diff --git a/akka-docs/rst/cluster/cluster-usage-scala.rst b/akka-docs/rst/cluster/cluster-usage-scala.rst index ea18cc7c61..f0dec3c590 100644 --- a/akka-docs/rst/cluster/cluster-usage-scala.rst +++ b/akka-docs/rst/cluster/cluster-usage-scala.rst @@ -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.://@:`. .. _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 should be on the format of - 'akka://actor-system-name@hostname:port' + 'akka.://@:' 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 diff --git a/akka-docs/rst/general/ActorPath.png b/akka-docs/rst/general/ActorPath.png index 988a2807dd..aef9b411aa 100644 Binary files a/akka-docs/rst/general/ActorPath.png and b/akka-docs/rst/general/ActorPath.png differ diff --git a/akka-docs/rst/general/RemoteDeployment.png b/akka-docs/rst/general/RemoteDeployment.png index 6898c64c96..119c94a5a8 100644 Binary files a/akka-docs/rst/general/RemoteDeployment.png and b/akka-docs/rst/general/RemoteDeployment.png differ diff --git a/akka-docs/rst/general/addressing.rst b/akka-docs/rst/general/addressing.rst index 15c814e511..fa8224c9d8 100644 --- a/akka-docs/rst/general/addressing.rst +++ b/akka-docs/rst/general/addressing.rst @@ -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 ^^^^^^^^^^^^^^^^^^^ diff --git a/akka-docs/rst/java/code/docs/remoting/RemoteDeploymentDocTestBase.java b/akka-docs/rst/java/code/docs/remoting/RemoteDeploymentDocTestBase.java index a3b659f4ac..ab7411118b 100644 --- a/akka-docs/rst/java/code/docs/remoting/RemoteDeploymentDocTestBase.java +++ b/akka-docs/rst/java/code/docs/remoting/RemoteDeploymentDocTestBase.java @@ -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 } diff --git a/akka-docs/rst/java/remoting.rst b/akka-docs/rst/java/remoting.rst index fae73cfde7..c7f50262be 100644 --- a/akka-docs/rst/java/remoting.rst +++ b/akka-docs/rst/java/remoting.rst @@ -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://@:/ + akka.://@:/ 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
). - -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
). - -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
). +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 `_ diff --git a/akka-docs/rst/java/untyped-actors.rst b/akka-docs/rst/java/untyped-actors.rst index 2acc8bbee1..c099fcecd3 100644 --- a/akka-docs/rst/java/untyped-actors.rst +++ b/akka-docs/rst/java/untyped-actors.rst @@ -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`` diff --git a/akka-docs/rst/project/migration-guide-2.1.x-2.2.x.rst b/akka-docs/rst/project/migration-guide-2.1.x-2.2.x.rst index a91a5cee09..e9b1a058bf 100644 --- a/akka-docs/rst/project/migration-guide-2.1.x-2.2.x.rst +++ b/akka-docs/rst/project/migration-guide-2.1.x-2.2.x.rst @@ -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` + + diff --git a/akka-docs/rst/scala/actors.rst b/akka-docs/rst/scala/actors.rst index 4f44497485..1cc6e0ea93 100644 --- a/akka-docs/rst/scala/actors.rst +++ b/akka-docs/rst/scala/actors.rst @@ -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`` diff --git a/akka-docs/rst/scala/remoting.rst b/akka-docs/rst/scala/remoting.rst index cf12c93c60..6b43516e21 100644 --- a/akka-docs/rst/scala/remoting.rst +++ b/akka-docs/rst/scala/remoting.rst @@ -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://@:/ + akka.://@:/ 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 `_