To be Reviewed By: October 8, 2021
Authors: Jens Deppe
Status: Draft | Discussion | Active | Dropped | Superseded
Superseded by: N/A
Related: N/A
To facilitate backwards compatibility, Geode has a concept known as Data Serializable Fixed ID (DSFID) which allows serializable objects to evolve over time using an API that allows newer versions of the classes to still be deserialized by older versions of Geode. This is a core capability of Geode that is primarily intended for internal classes but is also utilized by various modules, notably WAN, Lucene and Redis.
To use DSFIDs, a class needs to register itself so that it is known by the serialization framework. Many core classes register in DSFIDFactory . The modules, mentioned before, register during their service loader discovery and initialization phase. Under some situations, however, Geode will require knowledge of the DSFID very early on during member startup. If a member receives a message with an unknown DSFID it will throw a DSFIDNotFoundException. Without introducing module circular dependencies, there is no way for a module to register its required DSFIDs early enough to avoid this issue.
None identified.
The proposed solution has 2 parts:
Currently, the DSFIDSerializer interface exposes a registerDSFID(int dsfid, Class<?> dsfidClass) method. This method will be moved into a new interface ( DataSerializerFixedIdRegistrant ) and DSFIDSerialzer will extend this interface:
interface DataSerializeableFixedIdRegistry {
register(int id, Class<? extends DataSerializableFixedId> clazz);
} |
This will reduce the API surface area required by the following new service provider interface which would perform the actual Fixed Id registration:
interface DataSerializeableFixedIdRegistrant {
register(DataSerializableFixedIdRegistry registry);
} |
This SPI will be initialized as part of the static class initialization already existing in InternalDataSerializer .
In order to use this, a module will need to:
resources/META-INF/services/org.apache.geode.internal.serialization.DataSerializabledFixedIdRegistrantThe result will be that DSFIDs will be registered and available when the core serialization framework is instantiated.
Currently, an IllegalArgumentException is thrown, during registration, if the given class does not have a zero-argument constructor. This should be expanded to also produce an IllegalArgumentException if a registration is attempted for a previously registered ID.
No changes to public interfaces.
No anticipated performance impacts.
No backwards compatibility impact.
N/A
None yet.
None yet.