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)