[jira] [Comment Edited] (IGNITE-15944) [Networking] User object serialization

["Roman Puchkovskiy (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IGNITE-15944?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17460769#comment-17460769 ] 

Roman Puchkovskiy edited comment on IGNITE-15944 at 12/16/21, 2:22 PM:
-----------------------------------------------------------------------

A couple of issues were found in the spec that need to be discussed and resolved.
h3. Externalizable problem

Javadoc of Externalizable contains the following:
{quote}These methods [readExternal()/writeExternal()] must explicitly coordinate with the supertype to save its state
{quote}
This seems to mean that Externalizable#writeExternal() must save the state of the whole object, including the fields of its superclasses, not just the fields defined on the current class.

But our IEP says the following:
{quote}For an {{Externalizable}} class descriptor, only fields from the non- {{Externailzable}} hierarchy levels are included. The serialized layout is split into built-in region with automatic serialization of non-{{{}Externalizable{}}} levels, and the region produced by the {{writeExternal}} method.
{quote}
So in our IEP an Externalizable object is treated as composed of fields of (possibly non-Externalizable) superclasses plus the result of externalization of the fields of the current class.

In a case when the superclass is non-Externalizable, this would lead to the duplication of the superclass fields' data: they would be present in the 'non-Externalizable' region, and they would be somehow present in the externalization blob (as it should contain fields of all superclasses).

This duplication would not help in the following schema change case:
{quote}If the local class does not implement {{Externalizable}} interface, while remote class does, the externalizable region of the serialized class is skipped and either an exception is raised, or the section is passed to the optional handler that can initialize the skipped fields when possible. Note that deserialization cannot proceed in this case without user intervention.
{quote}
But it could help in another case:
{quote}If, on the contrary, local class implements {{Externalizable}} interface, but remote class does not, the {{readExternal}} method is ignored and read fields are assigned to the local object instance as if the class did not implement the {{Externalizable}} interface.
{quote}
Is it worth it to have this duplication just for this rare case?
h3. serialVersionUID
{quote}The serialization runtime associates with each serializable class a version number, called a serialVersionUID, which is used during deserialization to verify that the sender and receiver of a serialized object have loaded classes for that object that are compatible with respect to serialization. If the receiver has loaded a class for the object that has a different serialVersionUID than that of the corresponding sender's class, then deserialization will result in an InvalidClassException
{quote}
Should we support serialVersionUID or should we just ignore it completely?


was (Author: rpuch):
A couple of issues were found in the spec that need to be discussed and resolved.
h3. Externalizable problem

Javadoc of `Externalizable` contains the following:
{quote}These methods [readExternal()/writeExternal()] must explicitly coordinate with the supertype to save its state
{quote}
This seems to mean that `Externalizable#writeExternal()` must save the state of the whole object, including the fields of its superclasses, not just the fields defined on the current class.

But our IEP says the following:
{quote}For an {{Externalizable}} class descriptor, only fields from the non- {{Externailzable}} hierarchy levels are included. The serialized layout is split into built-in region with automatic serialization of non-{{{}Externalizable{}}} levels, and the region produced by the {{writeExternal}} method.
{quote}
So in our IEP an Externalizable object is treated as composed of fields of (possibly non-Externalizable) superclasses plus the result of externalization of the fields of the current class.

In a case when the superclass is non-Externalizable, this would lead to the duplication of the superclass fields' data: they would be present in the 'non-Externalizable' region, and they would be somehow present in the externalization blob (as it should contain fields of all superclasses).

This duplication would not help in the following schema change case:
{quote}If the local class does not implement {{Externalizable}} interface, while remote class does, the externalizable region of the serialized class is skipped and either an exception is raised, or the section is passed to the optional handler that can initialize the skipped fields when possible. Note that deserialization cannot proceed in this case without user intervention.
{quote}
But it could help in another case:
{quote}If, on the contrary, local class implements {{Externalizable}} interface, but remote class does not, the {{readExternal}} method is ignored and read fields are assigned to the local object instance as if the class did not implement the {{Externalizable}} interface.
{quote}
Is it worth it to have this duplication just for this rare case?
h3. serialVersionUID
{quote}The serialization runtime associates with each serializable class a version number, called a serialVersionUID, which is used during deserialization to verify that the sender and receiver of a serialized object have loaded classes for that object that are compatible with respect to serialization. If the receiver has loaded a class for the object that has a different serialVersionUID than that of the corresponding sender's class, then deserialization will result in an InvalidClassException
{quote}
Should we support serialVersionUID or should we just ignore it completely?

> [Networking] User object serialization
> --------------------------------------
>
>                 Key: IGNITE-15944
>                 URL: https://issues.apache.org/jira/browse/IGNITE-15944
>             Project: Ignite
>          Issue Type: Epic
>            Reporter: Semyon Danilov
>            Priority: Major
>              Labels: iep-67, ignite-3
>             Fix For: 3.0.0-alpha4
>
>
> Arbitrary objects serialization must be provided by Apache Ignite. Unlike {{NetworkMessage}} descendants, user objects are not known to the system in advance, and serialization layout must be resolved at runtime.
> For more information look at the https://github.com/gridgain/gridgain-9-ce/blob/iep-67/modules/network/README.md



--
This message was sent by Atlassian Jira
(v8.20.1#820001)