You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Roman Puchkovskiy (Jira)" <ji...@apache.org> on 2022/12/02 14:18:00 UTC

[jira] [Updated] (IGNITE-18319) Pass sender consistendId instead of ClusterNode to handler

     [ https://issues.apache.org/jira/browse/IGNITE-18319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Roman Puchkovskiy updated IGNITE-18319:
---------------------------------------
    Summary: Pass sender consistendId instead of ClusterNode to handler  (was: Handle 'sender is not in physical topology' when handling incoming message)

> 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.
> 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?



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