[
https://issues.apache.org/jira/browse/IGNITE-23372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-23372:
--------------------------------------
Description:
When a node joins a cluster, the coordinator validates it. But the joining node
validates the cluster configurations too. The question is when? Look at
{code:java}
GridComponnent#onGridDataReceived(GridDiscoveryData data)
{code}
For example, at
{code:java}
GridClusterStateProcessor#onGridDataReceived
{code}
or at
{code:java}
IgniteServiceProcessor#onGridDataReceived
{code}
They are called in
{code:java}
ServiceImpl#processNodeAddFinishedMessage(TcpDiscoveryNodeAddFinishedMessage
msg)
{code}
after
{code:java}
spiState = CONNECTED
{code}
`GridClusterStateProcessor` can fail here.
`IgniteServiceProcessor#GridClusterStateProcessor` have to validate received
service configurations before deployment and can fail here too (see
#IGNITE-23202).
It seems weird that node does some validations to joint cluster when it has
already joined, actually. This looks like a validation and issued failure at
finish of the second stage of a 2-phase commit when every participant has
already declared that it is OK and is ready to complete.
We should not do any validations with processing of
`TcpDiscoveryNodeAddFinishedMessage`. As an idea, processing of
`TcpDiscoveryNodeAddedMessage` is a better case.
was:
When a node joins a cluster, the coordinator validates it. But the joining node
validates the cluster configurations too. The question is when? Look at
{code:java}
GridComponnent#onGridDataReceived(GridDiscoveryData data)
{code}
For example, at
{code:java}
GridClusterStateProcessor#onGridDataReceived
{code}
or at
{code:java}
IgniteServiceProcessor#onGridDataReceived
{code}
They are called in `
{code:java}
ServiceImpl#processNodeAddFinishedMessage(TcpDiscoveryNodeAddFinishedMessage
msg)
{code}
after
{code:java}
spiState = CONNECTED
{code}
`GridClusterStateProcessor` can fail here.
`IgniteServiceProcessor#GridClusterStateProcessor` have to validate received
service configurations before deployment and can fail here too (see
#IGNITE-23202).
It seems weird that node does some validations to joint cluster when it has
already joined, actually. This looks like a validation and issued failure at
finish of the second stage of a 2-phase commit when every participant has
already declared that it is OK and is ready to complete.
We should not do any validations with processing of
`TcpDiscoveryNodeAddFinishedMessage`. As an idea, processing of
`TcpDiscoveryNodeAddedMessage` is a better case.
> Revise validation of received cluster data by a joining node.
> -------------------------------------------------------------
>
> Key: IGNITE-23372
> URL: https://issues.apache.org/jira/browse/IGNITE-23372
> Project: Ignite
> Issue Type: Improvement
> Reporter: Vladimir Steshin
> Priority: Minor
> Labels: ise
>
> When a node joins a cluster, the coordinator validates it. But the joining
> node validates the cluster configurations too. The question is when? Look at
> {code:java}
> GridComponnent#onGridDataReceived(GridDiscoveryData data)
> {code}
> For example, at
> {code:java}
> GridClusterStateProcessor#onGridDataReceived
> {code}
> or at
> {code:java}
> IgniteServiceProcessor#onGridDataReceived
> {code}
> They are called in
> {code:java}
> ServiceImpl#processNodeAddFinishedMessage(TcpDiscoveryNodeAddFinishedMessage
> msg)
> {code}
> after
> {code:java}
> spiState = CONNECTED
> {code}
> `GridClusterStateProcessor` can fail here.
> `IgniteServiceProcessor#GridClusterStateProcessor` have to validate received
> service configurations before deployment and can fail here too (see
> #IGNITE-23202).
> It seems weird that node does some validations to joint cluster when it has
> already joined, actually. This looks like a validation and issued failure at
> finish of the second stage of a 2-phase commit when every participant has
> already declared that it is OK and is ready to complete.
> We should not do any validations with processing of
> `TcpDiscoveryNodeAddFinishedMessage`. As an idea, processing of
> `TcpDiscoveryNodeAddedMessage` is a better case.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
