You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Roman Puchkovskiy (Jira)" <ji...@apache.org> on 2022/01/20 06:37:00 UTC

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

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

Roman Puchkovskiy commented on IGNITE-15944:
--------------------------------------------

One more problem.
h2. Avoiding to write a descriptor ID for 'effectively final' fields

We can avoid writing such descriptor ID only when we know for sure how to deserialize any possible value (of the given type).

For primitives it's easy: just the value needs to be written.

For non-primitives we must take into account the possibility to have a null. This means that we still need to write a discriminator that will allow us to reconstruct the situation during unmarshalling: was it null or not. So the example in the spec (last line of it, namely

{{0, null // child2 is Child2 with field1 and field 3 }}

) will not work: we'll need a null marker in the beginning of this sequence.

This can be solved if we add a built-in 'type' like NOT_NULL. For the cases when we know the concrete type for sure (those that are named 'effectively final' types in the spec), and the type is referential (i.e. non-primitive), we'll write either descriptor ID of NULL (for null) or that NOT_NULL marker (for a non-null reference) instead of writing the real type descriptor ID. In the worst case (when type descriptor ID is below 255 and can be written using one byte) we'll not save any space. But in cases when the type descriptor ID is over 255 (and requires at least 3 bytes to write), we'll spare 2 bytes.

> [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-alpha5
>
>
> 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)