Ivan Bessonov created IGNITE-20087:
--------------------------------------
Summary: Account for "nodeId" while sending the message
Key: IGNITE-20087
URL: https://issues.apache.org/jira/browse/IGNITE-20087
Project: Ignite
Issue Type: Improvement
Reporter: Ivan Bessonov
h3. Disclaimer
This change will, most likely, break some existing code.
h3. The problem
It is safe to assume, that the node shouldn't be able to send a message to
another node that doesn't exist. The way we solve this problem is sending a
message only to nodes that have corresponding {{ClusterNode}} instance, that
contains the address.
There are shortcuts in MessagingService, some methods only take the
"consistentId" parameter, but they really only send the message if there's a
known ClusterNode instance.
Internally, to identify the receiver, we use a pair \{consistentId, address}.
And it seems like this is not a good identifier. Following are the reasons:
* Node may reconnect with a different address
* Node may restart on the same address
In first case, everything should still work, but currently it, most likely,
won't.
In the second case, it shouldn't work, because we were trying to send the data
to the "old" node instance, assuming that it is statefull and is aware of the
possibility of such message. But it will work.
h3. The solution
To resolve these issues, we need to:
* validate the "nodeId", also known as a "launchId", of the connection, and
only use it if the actual value matches the expected one. If it doesn't, then
somebody has outdated ClusterNode instance, and they should be punished;
* don't use address as a part of the primary identifier of the channel. This
may require a substantial reworking of the way we process cluster nodes right
now, making it similar to the implementation in Ignite 2.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
