raboof/pekko
1
0
Fork 0
Code Issues Pull requests Projects Releases 6 Packages Wiki Activity Actions 11

Enable additional-serialization-bindings by default, #22169

Browse source 
* and thereby it was also possibe to simplify the documentation
  in remoting
This commit is contained in:
Patrik Nordwall 2017-01-24 16:29:48 +01:00
parent 554d119446
commit 9df49be5d0
11 changed files with 56 additions and 98 deletions
Download patch file Download diff file Expand all files Collapse all files

15
akka-actor/src/main/resources/reference.conf
View file

@ -586,16 +586,15 @@ akka {
"java.io.Serializable" = java "java.io.Serializable" = java
} }
# Set this to on to enable serialization-bindings define in # Set this to off to disable serialization-bindings define in
# additional-serialization-bindings. Those are by default not included # additional-serialization-bindings. That should only be needed
# for backwards compatibility reasons. They are enabled by default if # for backwards compatibility reasons.
# akka.remote.artery.enabled=on. enable-additional-serialization-bindings = on
enable-additional-serialization-bindings = off
# Additional serialization-bindings that are replacing Java serialization are # Additional serialization-bindings that are replacing Java serialization are
# defined in this section and not included by default for backwards compatibility # defined in this section for backwards compatibility reasons. They are included
# reasons. They can be enabled with enable-additional-serialization-bindings=on. # by default but can be excluded for backwards compatibility with Akka 2.4.x.
# They are enabled by default if akka.remote.artery.enabled=on. # They can be disabled with enable-additional-serialization-bindings=off.
additional-serialization-bindings { additional-serialization-bindings {
} }

1
akka-distributed-data/src/test/scala/akka/cluster/ddata/protobuf/ReplicatedDataSerializerSpec.scala
View file

@ -24,7 +24,6 @@ class ReplicatedDataSerializerSpec extends TestKit(ActorSystem(
akka.actor.provider=cluster akka.actor.provider=cluster
akka.remote.netty.tcp.port=0 akka.remote.netty.tcp.port=0
akka.remote.artery.canonical.port = 0 akka.remote.artery.canonical.port = 0
akka.actor.enable-additional-serialization-bindings=on
"""))) with WordSpecLike with Matchers with BeforeAndAfterAll { """))) with WordSpecLike with Matchers with BeforeAndAfterAll {
val serializer = new ReplicatedDataSerializer(system.asInstanceOf[ExtendedActorSystem]) val serializer = new ReplicatedDataSerializer(system.asInstanceOf[ExtendedActorSystem])

7
akka-docs/rst/java/remoting-artery.rst
View file

@ -444,15 +444,16 @@ Note that the array based methods can be implemented by delegation like this:
Disabling the Java Serializer Disabling the Java Serializer
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
With Artery it is possible to completely disable Java Serialization for the entire Actor system. It is possible to completely disable Java Serialization for the entire Actor system.
Java serialization is known to be slow and prone to attacks of various kinds - it never was designed for high Java serialization is known to be slow and prone to attacks of various kinds - it never was designed for high
throughput messaging after all. However it is very convenient to use, thus it remained the default serialization throughput messaging after all. However it is very convenient to use, thus it remained the default serialization
mechanism that Akka used to serialize user messages as well as some of its internal messages in previous versions. mechanism that Akka used to serialize user messages as well as some of its internal messages in previous versions.
Since the release of Artery, Akka internals do not rely on Java serialization anymore (exceptions to that being ``java.lang.Throwable`` and "remote deployment").
Akka internals do not rely on Java serialization (exceptions to that being ``java.lang.Throwable`` and "remote deployment").
.. note:: .. note::
When using Artery, Akka does not use Java Serialization for any of it's internal messages. Akka does not use Java Serialization for any of it's internal messages.
It is highly encouraged to disable java serialization, so please plan to do so at the earliest possibility you have in your project. It is highly encouraged to disable java serialization, so please plan to do so at the earliest possibility you have in your project.
One may think that network bandwidth and latency limit the performance of remote messaging, but serialization is a more typical bottleneck. One may think that network bandwidth and latency limit the performance of remote messaging, but serialization is a more typical bottleneck.

38
akka-docs/rst/java/remoting.rst
View file

@ -281,47 +281,21 @@ For more information please see :ref:`serialization-java`.
Disabling the Java Serializer Disabling the Java Serializer
----------------------------- -----------------------------
Since the ``2.4.11`` release of Akka it is possible to entirely disable the default Java Serialization mechanism. It is possible to completely disable Java Serialization for the entire Actor system.
Please note that :ref:`new remoting implementation (codename Artery) <remoting-artery-java>` does not use Java
serialization for internal messages by default. For compatibility reasons, the current remoting still uses Java
serialization for some classes, however you can disable it in this remoting implementation as well by following
the steps below.
The first step is to enable some additional serializers that replace previous Java serialization of some internal
messages. This is recommended also when you can't disable Java serialization completely. Those serializers are
enabled with this configuration:
.. code-block:: ruby
akka.actor {
# Set this to on to enable serialization-bindings define in
# additional-serialization-bindings. Those are by default not included
# for backwards compatibility reasons. They are enabled by default if
# akka.remote.artery.enabled=on.
enable-additional-serialization-bindings = on
}
The reason these are not enabled by default is wire-level compatibility between any 2.4.x Actor Systems.
If you roll out a new cluster, all on the same Akka version that can enable these serializers it is recommended to
enable this setting. When using :ref:`remoting-artery-java` these serializers are enabled by default.
.. warning::
Please note that when enabling the additional-serialization-bindings when using the old remoting,
you must do so on all nodes participating in a cluster, otherwise the mis-aligned serialization
configurations will cause deserialization errors on the receiving nodes.
Java serialization is known to be slow and prone to attacks of various kinds - it never was designed for high Java serialization is known to be slow and prone to attacks of various kinds - it never was designed for high
throughput messaging after all. However it is very convenient to use, thus it remained the default serialization throughput messaging after all. However it is very convenient to use, thus it remained the default serialization
mechanism that Akka used to serialize user messages as well as some of its internal messages in previous versions. mechanism that Akka used to serialize user messages as well as some of its internal messages in previous versions.
Since the release of Artery, Akka internals do not rely on Java serialization anymore (one exception being ``java.lang.Throwable``).
Akka internals do not rely on Java serialization (exceptions to that being ``java.lang.Throwable`` and "remote deployment").
.. note:: .. note::
When using the new remoting implementation (codename Artery), Akka does not use Java Serialization for any of it's internal messages. Akka does not use Java Serialization for any of it's internal messages.
It is highly encouraged to disable java serialization, so please plan to do so at the earliest possibility you have in your project. It is highly encouraged to disable java serialization, so please plan to do so at the earliest possibility you have in your project.
One may think that network bandwidth and latency limit the performance of remote messaging, but serialization is a more typical bottleneck. One may think that network bandwidth and latency limit the performance of remote messaging, but serialization is a more typical bottleneck.
For user messages, the default serializer, implemented using Java serialization, remains available and enabled in Artery. For user messages, the default serializer, implemented using Java serialization, remains available and enabled by default.
We do however recommend to disable it entirely and utilise a proper serialization library instead in order effectively utilise We do however recommend to disable it entirely and utilise a proper serialization library instead in order effectively utilise
the improved performance and ability for rolling deployments using Artery. Libraries that we recommend to use include, the improved performance and ability for rolling deployments using Artery. Libraries that we recommend to use include,
but are not limited to, `Kryo`_ by using the `akka-kryo-serialization`_ library or `Google Protocol Buffers`_ if you want but are not limited to, `Kryo`_ by using the `akka-kryo-serialization`_ library or `Google Protocol Buffers`_ if you want

22
akka-docs/rst/project/migration-guide-2.4.x-2.5.x.rst
View file

@ -283,6 +283,28 @@ It is still possible to make a rolling upgrade from a version < 2.4.12 by doing
For more information see the documentation for the ``akka.remote.netty.ssl.require-mutual-authentication`` configuration setting For more information see the documentation for the ``akka.remote.netty.ssl.require-mutual-authentication`` configuration setting
in :ref:`akka-remote's reference.conf <config-akka-remote>`. in :ref:`akka-remote's reference.conf <config-akka-remote>`.
additional-serialization-bindings
---------------------------------
From Akka 2.5.0 the ``additional-serialization-bindings`` are enabled by default. That defines
serializers that are replacing some Java serialization that were used in 2.4. This setting was disabled
by default in Akka 2.4.16 but can also be enabled in an Akka 2.4 system.
To still be able to support rolling upgrade from a system with this setting disabled, e.g. default for 2.4.16,
it is possible to disable the additional serializers and continue using Java serialization for those messages.
.. code-block:: ruby
akka.actor {
# Set this to off to disable serialization-bindings define in
# additional-serialization-bindings. That should only be needed
# for backwards compatibility reasons.
enable-additional-serialization-bindings = off
}
Please note that this setting must be the same on all nodes participating in a cluster, otherwise
the mis-aligned serialization configurations will cause deserialization errors on the receiving nodes.
Cluster Cluster
======= =======

7
akka-docs/rst/scala/remoting-artery.rst
View file

@ -444,15 +444,16 @@ Note that the array based methods can be implemented by delegation like this:
Disabling the Java Serializer Disabling the Java Serializer
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
With Artery it is possible to completely disable Java Serialization for the entire Actor system. It is possible to completely disable Java Serialization for the entire Actor system.
Java serialization is known to be slow and prone to attacks of various kinds - it never was designed for high Java serialization is known to be slow and prone to attacks of various kinds - it never was designed for high
throughput messaging after all. However it is very convenient to use, thus it remained the default serialization throughput messaging after all. However it is very convenient to use, thus it remained the default serialization
mechanism that Akka used to serialize user messages as well as some of its internal messages in previous versions. mechanism that Akka used to serialize user messages as well as some of its internal messages in previous versions.
Since the release of Artery, Akka internals do not rely on Java serialization anymore (exceptions to that being ``java.lang.Throwable`` and "remote deployment").
Akka internals do not rely on Java serialization (exceptions to that being ``java.lang.Throwable`` and "remote deployment").
.. note:: .. note::
When using Artery, Akka does not use Java Serialization for any of it's internal messages. Akka does not use Java Serialization for any of it's internal messages.
It is highly encouraged to disable java serialization, so please plan to do so at the earliest possibility you have in your project. It is highly encouraged to disable java serialization, so please plan to do so at the earliest possibility you have in your project.
One may think that network bandwidth and latency limit the performance of remote messaging, but serialization is a more typical bottleneck. One may think that network bandwidth and latency limit the performance of remote messaging, but serialization is a more typical bottleneck.

38
akka-docs/rst/scala/remoting.rst
View file

@ -287,47 +287,21 @@ For more information please see :ref:`serialization-scala`.
Disabling the Java Serializer Disabling the Java Serializer
----------------------------- -----------------------------
Since the ``2.4.11`` release of Akka it is possible to entirely disable the default Java Serialization mechanism. It is possible to completely disable Java Serialization for the entire Actor system.
Please note that :ref:`new remoting implementation (codename Artery) <remoting-artery-scala>` does not use Java
serialization for internal messages by default. For compatibility reasons, the current remoting still uses Java
serialization for some classes, however you can disable it in this remoting implementation as well by following
the steps below.
The first step is to enable some additional serializers that replace previous Java serialization of some internal
messages. This is recommended also when you can't disable Java serialization completely. Those serializers are
enabled with this configuration:
.. code-block:: ruby
akka.actor {
# Set this to on to enable serialization-bindings define in
# additional-serialization-bindings. Those are by default not included
# for backwards compatibility reasons. They are enabled by default if
# akka.remote.artery.enabled=on.
enable-additional-serialization-bindings = on
}
The reason these are not enabled by default is wire-level compatibility between any 2.4.x Actor Systems.
If you roll out a new cluster, all on the same Akka version that can enable these serializers it is recommended to
enable this setting. When using :ref:`remoting-artery-scala` these serializers are enabled by default.
.. warning::
Please note that when enabling the additional-serialization-bindings when using the old remoting,
you must do so on all nodes participating in a cluster, otherwise the mis-aligned serialization
configurations will cause deserialization errors on the receiving nodes.
Java serialization is known to be slow and prone to attacks of various kinds - it never was designed for high Java serialization is known to be slow and prone to attacks of various kinds - it never was designed for high
throughput messaging after all. However it is very convenient to use, thus it remained the default serialization throughput messaging after all. However it is very convenient to use, thus it remained the default serialization
mechanism that Akka used to serialize user messages as well as some of its internal messages in previous versions. mechanism that Akka used to serialize user messages as well as some of its internal messages in previous versions.
Since the release of Artery, Akka internals do not rely on Java serialization anymore (one exception being ``java.lang.Throwable``).
Akka internals do not rely on Java serialization (exceptions to that being ``java.lang.Throwable`` and "remote deployment").
.. note:: .. note::
When using the new remoting implementation (codename Artery), Akka does not use Java Serialization for any of it's internal messages. Akka does not use Java Serialization for any of it's internal messages.
It is highly encouraged to disable java serialization, so please plan to do so at the earliest possibility you have in your project. It is highly encouraged to disable java serialization, so please plan to do so at the earliest possibility you have in your project.
One may think that network bandwidth and latency limit the performance of remote messaging, but serialization is a more typical bottleneck. One may think that network bandwidth and latency limit the performance of remote messaging, but serialization is a more typical bottleneck.
For user messages, the default serializer, implemented using Java serialization, remains available and enabled in Artery. For user messages, the default serializer, implemented using Java serialization, remains available and enabled by default.
We do however recommend to disable it entirely and utilise a proper serialization library instead in order effectively utilise We do however recommend to disable it entirely and utilise a proper serialization library instead in order effectively utilise
the improved performance and ability for rolling deployments using Artery. Libraries that we recommend to use include, the improved performance and ability for rolling deployments using Artery. Libraries that we recommend to use include,
but are not limited to, `Kryo`_ by using the `akka-kryo-serialization`_ library or `Google Protocol Buffers`_ if you want but are not limited to, `Kryo`_ by using the `akka-kryo-serialization`_ library or `Google Protocol Buffers`_ if you want

7
akka-remote/src/main/resources/reference.conf
View file

@ -51,9 +51,10 @@ akka {
"java.util.Optional" = akka-misc "java.util.Optional" = akka-misc
} }
# For the purpose of preserving protocol backward compatibility these bindings are not # Additional serialization-bindings that are replacing Java serialization are
# included by default. They can be enabled with enable-additional-serialization-bindings=on. # defined in this section for backwards compatibility reasons. They are included
# They are enabled by default if akka.remote.artery.enabled=on. # by default but can be excluded for backwards compatibility with Akka 2.4.x.
# They can be disabled with enable-additional-serialization-bindings=off.
additional-serialization-bindings { additional-serialization-bindings {
"akka.actor.Identify" = akka-misc "akka.actor.Identify" = akka-misc
"akka.actor.ActorIdentity" = akka-misc "akka.actor.ActorIdentity" = akka-misc

4
akka-remote/src/test/scala/akka/remote/serialization/MiscMessageSerializerSpec.scala
View file

@ -17,10 +17,6 @@ import java.io.NotSerializableException
object MiscMessageSerializerSpec { object MiscMessageSerializerSpec {
val serializationTestOverrides = val serializationTestOverrides =
""" """
akka.actor.enable-additional-serialization-bindings=on
# or they can be enabled with
# akka.remote.artery.enabled=on
akka.actor.serialization-bindings { akka.actor.serialization-bindings {
"akka.remote.serialization.MiscMessageSerializerSpec$TestException" = akka-misc "akka.remote.serialization.MiscMessageSerializerSpec$TestException" = akka-misc
} }

9
akka-remote/src/test/scala/akka/remote/serialization/PrimitivesSerializationSpec.scala
View file

@ -16,9 +16,6 @@ import scala.util.Random
object PrimitivesSerializationSpec { object PrimitivesSerializationSpec {
val serializationTestOverrides = val serializationTestOverrides =
""" """
akka.actor.enable-additional-serialization-bindings=on
# or they can be enabled with
# akka.remote.artery.enabled=on
""" """
val testConfig = ConfigFactory.parseString(serializationTestOverrides).withFallback(AkkaSpec.testConf) val testConfig = ConfigFactory.parseString(serializationTestOverrides).withFallback(AkkaSpec.testConf)
@ -96,8 +93,7 @@ class PrimitivesSerializationSpec extends AkkaSpec(PrimitivesSerializationSpec.t
"empty string" → "", "empty string" → "",
"hello" → "hello", "hello" → "hello",
"árvíztűrőütvefúrógép" → "árvíztűrőütvefúrógép", "árvíztűrőütvefúrógép" → "árvíztűrőütvefúrógép",
"random" → random "random" → random).foreach {
).foreach {
case (scenario, item) ⇒ case (scenario, item) ⇒
s"resolve serializer for [$scenario]" in { s"resolve serializer for [$scenario]" in {
val serializer = SerializationExtension(system) val serializer = SerializationExtension(system)
@ -132,8 +128,7 @@ class PrimitivesSerializationSpec extends AkkaSpec(PrimitivesSerializationSpec.t
"empty string" → ByteString.empty, "empty string" → ByteString.empty,
"simple content" → ByteString("hello"), "simple content" → ByteString("hello"),
"concatenated content" → (ByteString("hello") ++ ByteString("world")), "concatenated content" → (ByteString("hello") ++ ByteString("world")),
"sliced content" → ByteString("helloabc").take(5) "sliced content" → ByteString("helloabc").take(5)).foreach {
).foreach {
case (scenario, item) ⇒ case (scenario, item) ⇒
s"resolve serializer for [$scenario]" in { s"resolve serializer for [$scenario]" in {
val serializer = SerializationExtension(system) val serializer = SerializationExtension(system)

6
akka-remote/src/test/scala/akka/remote/serialization/SystemMessageSerializationSpec.scala
View file

@ -10,9 +10,6 @@ import com.typesafe.config.ConfigFactory
object SystemMessageSerializationSpec { object SystemMessageSerializationSpec {
val serializationTestOverrides = val serializationTestOverrides =
""" """
akka.actor.enable-additional-serialization-bindings=on
# or they can be enabled with
# akka.remote.artery.enabled=on
""" """
val testConfig = ConfigFactory.parseString(serializationTestOverrides).withFallback(AkkaSpec.testConf) val testConfig = ConfigFactory.parseString(serializationTestOverrides).withFallback(AkkaSpec.testConf)
@ -43,8 +40,7 @@ class SystemMessageSerializationSpec extends AkkaSpec(PrimitivesSerializationSpe
"Unwatch(ref, ref)" → Unwatch(testRef, testRef2), "Unwatch(ref, ref)" → Unwatch(testRef, testRef2),
"Failed(ref, ex, uid)" → Failed(testRef, new TestException("test4"), 42), "Failed(ref, ex, uid)" → Failed(testRef, new TestException("test4"), 42),
"DeathWatchNotification(ref, confimed, addressTerminated)" → "DeathWatchNotification(ref, confimed, addressTerminated)" →
DeathWatchNotification(testRef, existenceConfirmed = true, addressTerminated = true) DeathWatchNotification(testRef, existenceConfirmed = true, addressTerminated = true)).foreach {
).foreach {
case (scenario, item) ⇒ case (scenario, item) ⇒
s"resolve serializer for [$scenario]" in { s"resolve serializer for [$scenario]" in {
val serializer = SerializationExtension(system) val serializer = SerializationExtension(system)