I found a strange call to `drop()` in `ByteString1.writeToBuffer(ByteBuffer)`. `drop()` instantiates a new `ByteString1` which is immediately discarded to GC. Appears unnecessary.
Removing it makes the `ByteString1` implementation match the one `ByteString1C`.
I just got burned by #16303.
Answering https://github.com/akka/akka/issues/16303#issuecomment-62957914, it looks like `copyToArray[B >: Byte](Array[B])` can't call `getBytes(Array[Byte], Int, Int)` due to the type constraint (defined by `GenTraversableOnce`).
Instead, I'm going with the simple `isEmpty` solution proposed in the description of #16303 by @kpatrick-kixeye.
* The ThreadLocal Serialization.currentTransportInformation is used for serializing local
actor refs, but it's also useful when a serializer library e.g. custom serializer/deserializer
in Jackson need access to the current ActorSystem.
* We set this in a rather ad-hoc way from remoting and in some persistence plugins, but it's only
set for serialization and not deserialization, and it's easy for Persistence plugins or other
libraries to forget this when using Akka serialization directly.
* This change is automatically setting the info when using the ordinary serialize and deserialize
methods.
* It's also set when LocalActorRefProvider, which wasn't always the case previously.
* Keep a cached instance of Serialization.Information in the provider to avoid
creating new instances all the time.
* Added optional Persistence TCK tests to verify that the plugin is setting this
if it's using some custom calls to the serializer.
Each build is now over 40mb logs.
A lot of DEBUG logging was left on for test failures that have been
fixed. Added an issue # for ones that are still valid or if if it on
as the test verifies debug
AutoReceivedMessage with FSM schedule bug fixed (#24080)
Tests added for both FSM and Timers trait for (#24080)
AutoReceivedMessage with PersistentFSM bug fixed and test added (#24080)
* Specific message for serialize-messages errors
Give users some pointers where to look when this happens.
* Add copyright header
* Introduce SerializationCheckFailedException
* Use try rather than Try
* The classical problem when case class is extending a marker interface that is
configured to a specific serializer, java.io.Serializable and the marker
interface have no order. Multiple serializers found and then it is picking
the first one.
* This changes that behavior so that if multiple serializers are found it gives
JavaSerializer low priority and chooses the other serializer.
* This might look like a scary change from a compatibility perspective, but
it should be fine becuse it is not influencing deserialization. The previous
choice for serialization was pretty random so this choice should not make
it worse.
