https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/CONTROLLER-2072 controller <p>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.</p> <p>This will allow us to not shade Kryo, significantly reducing the amount of classes we ship.</p> CONTROLLER-2072

Remove Kryo from atomix-storage

Improvement High In Review Unresolved Samuel Schneider Robert Varga pick-next pt Thu, 2 Mar 2023 12:46:12 +0000 Fri, 29 Dec 2023 07:46:34 +0000 8.0.5 clustering 0 2 <p>Patches leading to <a href="https://git.opendaylight.org/gerrit/c/controller/+/104745" class="external-link" target="_blank" rel="nofollow noopener">https://git.opendaylight.org/gerrit/c/controller/+/104745</a> 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:</p> <ul> <li>keeping track of registration IDs and their manifestation in the serialized format</li> <li>implementing EntryInput/EntryOutput is a binary compatible way, of which</li> <li>perhaps readObject()/writeObject() are the most bothersome, but should boil down to Externalizable serialization, which in turn sal-akka-segmented-journal can enforce</li> </ul> <p> </p> <p>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.</p> <p>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? </p> <p>Depends on how much of that we are <b>really</b> using in the codepaths we are taking.</p> Blocks CONTROLLER-2044 CONTROLLER-2071 Development Rank 0|i044gf: