Anton Vinogradov created IGNITE-28942:
-----------------------------------------

             Summary: Evaluate replacing JdkMarshaller with binary in a 
self-contained mode
                 Key: IGNITE-28942
                 URL: https://issues.apache.org/jira/browse/IGNITE-28942
             Project: Ignite
          Issue Type: Sub-task
          Components: messaging
            Reporter: Anton Vinogradov
            Assignee: Anton Vinogradov
             Fix For: 2.19


*Research task. No production change expected from this ticket.*

h3. Goal

Answer, with numbers, whether {{JdkMarshaller}} can be dropped and binary used 
everywhere.

h3. Why

"Binary needs discovery" is not true of the format. When a type is not 
registered, binary writes {{UNREGISTERED_TYPE_ID}} plus the class name 
({{BinaryWriterExImpl#preWrite}}), and metadata can be kept local 
({{registerClassNameLocally}}, {{addMetaLocally}}). Thin client, JDBC and the 
standalone WAL reader already run binary without any cluster.

First measurements:
* with a full footer the object is self-contained. An object written by one 
context is read by a completely empty context, cycles included: 84 bytes 
against 121 for jdk on the same POJO.
* with the default compact footer the same object cannot be read: "Cannot find 
metadata for object with compact footer". The field layout still comes from 
metadata, which discovery distributes.
* the unregistered path is slow today: 160 us against 24 for a 
{{CacheConfiguration}}, because the descriptor of an unregistered type is 
rebuilt by reflection on every call.

h3. How

Answer these questions:
# a per-call full-footer mode - {{compactFooter}} is a node-wide setting now;
# caching descriptors of unregistered types, and what the numbers become after 
that;
# class-name filtering on the unregistered path: 
{{JdkMarshallerObjectInputStream}} and {{OptimizedObjectInputStream}} pass the 
filter into {{CommonUtils#forName}}, while {{BinaryUtils#doReadClass}} passes 
{{null}}. Note that {{forName}} only consults the filter on a class-cache miss, 
so any check must run in a fresh JVM;
# on-disk formats: cache configurations, metastore, snapshots and dumps are 
written with jdk and read by offline tools, so this is a data migration, not a 
code change;
# what stays anyway: binary delegates every {{Externalizable}} type to 
{{OptimizedMarshaller}}, so the count goes from three implementations to two, 
not to one.

h3. Expected result

A decision backed by numbers: either a plan with the four items above, or a 
documented "not worth it" so that the question stops coming back.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to