[
https://issues.apache.org/jira/browse/IGNITE-28941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-28941:
--------------------------------------
Description:
*No wire format change.*
h3. Goal
Check the rule "do not use the binary marshaller on the discovery path" in CI.
h3. Why
Today this rule is only a convention. In one place it works by luck:
{{BinaryMetadataVersionInfo}} uses binary inside the jdk discovery data bag. It
works because {{BinaryMetadata}}, {{BinarySchema}} and {{BinaryFieldMetadata}}
are listed in {{META-INF/classnames.properties}} (2276 names), so
{{registerClassName}} returns at once. A new class outside this file would
block the discovery thread in {{fut.get()}}.
h3. How
* walk the message tree that starts from discovery messages (message factory
and {{@Order}} fields), and check that no field uses the binary marshaller;
* optional: add an assert in {{MarshallerContextImpl#registerClassName}} that
it is not called from the discovery worker thread.
h3. Expected result
The rule is checked by CI, so a new message cannot bring the deadlock back.
h3. How to verify
The test must fail on a message marked wrong on purpose, and pass on master
after the other subtasks.
was:
h3. Goal
Turn the unwritten rule "the schema-aware marshaller is not allowed on the
discovery path" into a check that fails in CI.
h3. Why
The rule is kept by convention only, and in at least one place it holds by
luck: {{BinaryMetadataVersionInfo}} is marshalled with binary inside the jdk
discovery data bag {{CacheBinaryDataBagItem}}, and works only because
{{BinaryMetadata}}, {{BinarySchema}} and {{BinaryFieldMetadata}} are listed in
{{META-INF/classnames.properties}} (2276 pre-accepted names), so
{{registerClassName}} returns without a ring round-trip. A new type outside
that file would block the discovery thread on {{fut.get()}}.
h3. How
* walk the message tree reachable from discovery messages - message factory
plus {{@Order}} fields - and assert that no field on that path is marshalled
with the schema-aware marshaller;
* optionally add an assertion in {{MarshallerContextImpl#registerClassName}}
that it is never called from the discovery worker thread.
h3. Expected result
A rule that is checked instead of remembered, so the deadlock cannot be
reintroduced by a future message.
h3. How to verify
The test must fail on a deliberately mis-marked message and pass on master once
the other subtasks are in.
Summary: Add a test: discovery messages must not need cluster class
registration (was: Test that discovery messages never require cluster-wide
class registration)
> Add a test: discovery messages must not need cluster class registration
> -----------------------------------------------------------------------
>
> Key: IGNITE-28941
> URL: https://issues.apache.org/jira/browse/IGNITE-28941
> Project: Ignite
> Issue Type: Sub-task
> Components: messaging
> Reporter: Anton Vinogradov
> Assignee: Anton Vinogradov
> Priority: Major
> Fix For: 2.19
>
>
> *No wire format change.*
> h3. Goal
> Check the rule "do not use the binary marshaller on the discovery path" in CI.
> h3. Why
> Today this rule is only a convention. In one place it works by luck:
> {{BinaryMetadataVersionInfo}} uses binary inside the jdk discovery data bag.
> It works because {{BinaryMetadata}}, {{BinarySchema}} and
> {{BinaryFieldMetadata}} are listed in {{META-INF/classnames.properties}}
> (2276 names), so {{registerClassName}} returns at once. A new class outside
> this file would block the discovery thread in {{fut.get()}}.
> h3. How
> * walk the message tree that starts from discovery messages (message factory
> and {{@Order}} fields), and check that no field uses the binary marshaller;
> * optional: add an assert in {{MarshallerContextImpl#registerClassName}} that
> it is not called from the discovery worker thread.
> h3. Expected result
> The rule is checked by CI, so a new message cannot bring the deadlock back.
> h3. How to verify
> The test must fail on a message marked wrong on purpose, and pass on master
> after the other subtasks.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
