[
https://issues.apache.org/jira/browse/IGNITE-18319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-18319:
---------------------------------------
Description:
Currently, {{DefaultMessagingService#onMessage()}} throws an {{AssertionError}}
if the message sender is not in the physical topology.
As this is an expected behavior (a node can sometimes leave), it seems correct
to handle this gracefully.
The idea is to allow the handler resolve node by consistentId by itself and
then decide what to do with a missing {{{}sender{}}}. Some of handlers don't
even care about the sender because they do not send any response. There is also
one handler that only cares about consistentId.
A thing to reflect on: a node might disappear from a physical topology because
of one of the two reaasons: either network connectivity is lost for some time,
or a node stopped (maybe as a part of a restart). Do we need to account for
this difference?
was:
Currently, {{DefaultMessagingService#onMessage()}} throws an {{AssertionError}}
if the message sender is not in the physical topology.
As this is an expected behavior (a node can sometimes leave), it seems correct
to handle this gracefully.
One idea is to allow the handler decide what to do with a null {{{}sender{}}}.
Some of handlers don't even care about the sender because they do not send any
response.
A thing to reflect on: a node might disappear from a physical topology because
of one of the two reaasons: either network connectivity is lost for some time,
or a node stopped (maybe as a part of a restart). Do we need to account for
this difference?
> Pass sender consistendId instead of ClusterNode to handler
> ----------------------------------------------------------
>
> Key: IGNITE-18319
> URL: https://issues.apache.org/jira/browse/IGNITE-18319
> Project: Ignite
> Issue Type: Bug
> Components: networking
> Reporter: Roman Puchkovskiy
> Assignee: Roman Puchkovskiy
> Priority: Major
> Labels: ignite-3, tech-debt
>
> Currently, {{DefaultMessagingService#onMessage()}} throws an
> {{AssertionError}} if the message sender is not in the physical topology.
> As this is an expected behavior (a node can sometimes leave), it seems
> correct to handle this gracefully.
> The idea is to allow the handler resolve node by consistentId by itself and
> then decide what to do with a missing {{{}sender{}}}. Some of handlers don't
> even care about the sender because they do not send any response. There is
> also one handler that only cares about consistentId.
> A thing to reflect on: a node might disappear from a physical topology
> because of one of the two reaasons: either network connectivity is lost for
> some time, or a node stopped (maybe as a part of a restart). Do we need to
> account for this difference?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
