[
https://issues.apache.org/jira/browse/IGNITE-28901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18101503#comment-18101503
]
Anton Vinogradov commented on IGNITE-28901:
-------------------------------------------
I reworked the patch after a second look, so the PR now does something wider
than the summary of this ticket says. Worth re-reading before review.
The first version kept one message class and only moved the filter onto the
generated marshalling. That works, but it needs two crutches, and both come
from the same place: the class serves the request and the response at once, and
the two halves never overlap - the request constructor nulls {{evts}} and
{{errMsg}}, the response constructor nulls the six request fields.
Because deferral applies to a whole message and not to a field, making the
request deferred also deferred the response, which then had to be unmarshalled
by hand in its listener. And the response topic, sent as a marshalled
{{GridTopic}} tuple, had to be unmarshalled separately and ahead of everything
else, because a failure to resolve the deployment still has to be answered and
the answer goes to that topic.
The split removes both. {{GridEventStorageResponse}} is a plain {{Message}}
again and its listener is back to what it was. {{GridEventStorageRequest}}
carries the id of the waiting node instead of a topic blob, and rebuilds
{{TOPIC_EVENT.topic(id)}} on the other side. One
{{MessageMarshalling.unmarshal}} call is left - the filter, after the
deployment is resolved.
Two consequences for the triage:
# this is now a wire format change (two message types, fields split, topic as
{{IgniteUuid}}), so the {{wire-format}} label and the 2.19 fixVersion stay -
unlike what I wrote earlier, when the patch was wire-neutral;
# the summary of this ticket says "revise the filters marshalling", and the
work is now "split the message". Renaming it would make the history easier to
read.
> Revise GridEventStorageMessage filters (un)marshalling
> ------------------------------------------------------
>
> Key: IGNITE-28901
> URL: https://issues.apache.org/jira/browse/IGNITE-28901
> Project: Ignite
> Issue Type: Task
> Reporter: Anton Vinogradov
> Assignee: Anton Vinogradov
> Priority: Major
> Labels: IEP-132, wire-format
> Fix For: 2.19
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> GridEventStorageMessage carries the remote event filter as a manual byte[]
> blob (filterBytes/filter) with a hand-written deferred unmarshal step:
> finishUnmarshalFilters(marsh, filterClsLdr) is invoked by
> GridEventStorageManager at processing time, once the peer-deployment class
> loader for the filter is resolved.
> This is the only (un)marshalling in core left outside the
> generated-marshaller flow (IGNITE-28520): the generated unmarshal runs at
> receive time with the configuration/peer loader available then, while the
> filter must be deserialized later with a loader resolved per-filter from
> deployment info, so @Marshalled cannot express it.
> Options to explore:
> * a deferred flavour of @Marshalled: the companion stays serialized at
> receive; a generated unmarshalDeferred(ClassLoader) restores it on demand;
> * or keep the manual step but align its naming/shape with the
> marshal/unmarshal hook family and document why it is manual.
> Follow-up of IGNITE-28520.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
