Handle akka FQCNs

[pjfanning]

• Based on Provide a way to handle upcoming remote wire incompatibility apache/pekko#108 (comment)
• If it makes sense to try to fail over if we can't load akka classes to autocorrecting the FQCN to have org.apache.pekko prefix, it may also be useful to do the equivalent in https://github.com/altoo-ag/akka-kryo-serialization
• we also have deserializing persisted data that has akka classnames apache/pekko#604

[nvollmar]

I don't think any of those cases applies. Akka/Pekko are using protobuf for serialization of internal messages, our library is used to serialize application specific messages which typically shouldn't be in the Akka or Pekko package.

And it is not recommended to use Kryo serialization for persistent data in general, as Kryo does not guarantee any backwards compatibility.

[danischroeter]

I don't think any of those cases applies. Akka/Pekko are using protobuf for serialization of internal messages, our library is used to serialize application specific messages which typically shouldn't be in the Akka or Pekko package.

Agree - I also don't see a valid/existing straight forward usecase.
However we need to check the case where a custom message is used that contains an akka internal. E.g. a custom message with an ActorRef - ideally this would be converted from pekko<->akka

[nvollmar]

I took a look at it. We have custom serializer for ByteString and ActorRef, the two classes that most likely might be in custom messages.

kryo.addDefaultSerializer(classOf[org.apache.pekko.util.ByteString], new ByteStringSerializer())
kryo.addDefaultSerializer(classOf[org.apache.pekko.actor.ActorRef], new ActorRefSerializer(system))

It then comes down to the id-strategy:

• If id-strategy = default or id-strategy = automatic (without registration) are used, the FQCN is serialized. In that case the Pekko system would need a dummy class akka.actor.ActorRef to create a class object to register the Pekko serializer. It would then just deserialize Akka ActorRef to Pekko ActorRef. Same for ByteString.
• If id-strategy = explicit is used, nothing needed to be done if the Akka and Pekko classes use the same id. The serializer would just happily deserialize to Pekko classes.

[danischroeter]

Nice.
I propose we document this in a "Migration from akka section".
As for the dummy classes we could create a pekko-kryo-serialization-akka-compat artifact with the dummy classes etc in there to ease transition.

@nvollmar wdyt?

[nvollmar]

That one could also provide a CompatKryoInitializer that does the necessary registrations.

We should also create a serialized sample with akka-kryo-serialization to test in pekko-kryo-serialization-akka-compat

[nvollmar]

@pjfanning I have a working prototype where I can deserialize a sample message with an Akka ActorRef in a Pekko system (assuming the message has the same FQCN (or mapping id) and parameter list in both systems).

One detail that is important for the final implementation is whether the Pekko system will use "pekko://" or will to be configured to use "akka://" for the migration. For the former the serializer would need to do a search replace of the protocol.