Remove Kryo from atomix-storage

Description

We do not need full serdes capabilities of Kryo, certainly not its ASM/Objenesis dependencies. Examine the interplay of sal-akka-segmented-journal with Kryo and replace it with a simpler interface, which will result in binary-compatible serialization format.

This will allow us to not shade Kryo, significantly reducing the amount of classes we ship.

Activity

Show:

Robert Varga June 1, 2023 at 2:14 PM

Depends on how much of that we are really using in the codepaths we are taking.

Tibor Král June 1, 2023 at 1:08 PM

In terms of us implementing EntryInput/EntryOutput in a binary compatible way, we'll probably need to directly reuse the implementation from com.esotericsoftware.kryo.io.Output and Input classes. Basically a copy-paste into our EntryInput/EntryOutput classes. I don't like this approach. Do we have any other choice? 

Robert Varga March 2, 2023 at 8:39 PM

Also, the @VisibleForTesting methods can actually be replaced with either a plain DataOutput.writeInt(), or perhaps WritableObjects.writeLong() – it is just testing, we do not actually need that.

Robert Varga March 2, 2023 at 8:37 PM

Patches leading to https://git.opendaylight.org/gerrit/c/controller/+/104745 encapulate Kryo so users are not directly exposed to it, while defanging the implementation. At that patch Kryo is an implementation detail and can be replaced by providing an alternative to KryoJournalSerdes – which really boils down to:

  • keeping track of registration IDs and their manifestation in the serialized format

  • implementing EntryInput/EntryOutput is a binary compatible way, of which

  • perhaps readObject()/writeObject() are the most bothersome, but should boil down to Externalizable serialization, which in turn sal-akka-segmented-journal can enforce

 

Details

Assignee

Reporter

Labels

Components

Fix versions

Priority

Created March 2, 2023 at 12:46 PM
Updated March 10, 2025 at 12:21 PM