[ https://issues.apache.org/jira/browse/IGNITE-18121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexander Lapin updated IGNITE-18121: ------------------------------------- Description: h3. Motivation Within IGNITE-18115 reaction to the topology events was introduced as an immediate ms.invoke that will try to update zones.<zone>.dataNodes key. In fact, we should defer state recalculation for some time specified by the user in order to accumulate contiguous topology events. Please check following example for more details: |-1|start Node A; start Node B; start Node C; CREATE ZONE zone1 WITH DATA_NODES_AUTO_ADJUST_{*}SCALE_UP{*} = 300; CREATE TABLE Accounts … WITH PRIMARY_ZONE = zone1 |User starts three Ignite nodes A, B, C and creates table Accounts specifying scale up auto adjust timeout as 300 seconds. Accounts table is created on current topology, meaning that <Transaction>.dataNodes = [A,B,C]| |0|start Node D -> Node D join/validation -> D enters logical topology -> logicalTopology.onNodeAdded(Node D) -> scale_up_auto_adjust(300) timer is scheduled for the <Accounts> table.|At time 0 seconds the user starts one more Ignite node D, that joins the cluster. On entering logical topology the onNodeAdded event is fired. This event schedules a timer of 300 seconds for table Accounts after which the dataNodes of that table transitively through the distribution zone will be recalculated from [A,B,C] to [A,B,C,D] | |250|start Node E -> scale_up_auto_adjust(300) is {*}re{*}scheduled for the <Accounts> table.|At 250 seconds one more node is added, that action reschedules scale_up_auto_adjust timer for another 300 seconds.| |550|scale_up_auto_adjust fired -> set table.<Accounts>.dataNodes = [NodeA, NodeB, NodeC, Node D, Node E]|At 550 seconds scale_up_time is fired, that leads to <Transaction>dataNodes recalculation by attaching the nodes that were added to logical topology - Nodes D and E in the given example.| |600|start Node F -> <Accounts> table schedules scale_up_auto_adjust(300);|At 600 seconds one more node is added, there are no active scale_up_auto_adjust timers, so given events schedules new one.| Thus it's required to modify ms topology handler in a way that it should schedule or re-schedule a timer that will eventually call ms.invoke(dataNodes). h3. Definition of Done * DataNodes recalculation is delayed for dataNodesAutoAdjustScaleUp value. * In case of new scale up toplogy event, existing scale up timers should be re-scheduled. h3. Implemention Notes As usual, pretty straight forward, ScheduledExecutorService with proper naming should be introduced. Busy locks and proper scheduler stopping required. > Introduce scale up scheduler > ---------------------------- > > Key: IGNITE-18121 > URL: https://issues.apache.org/jira/browse/IGNITE-18121 > Project: Ignite > Issue Type: Improvement > Reporter: Alexander Lapin > Priority: Major > Labels: ignite-3 > > h3. Motivation > Within IGNITE-18115 reaction to the topology events was introduced as an > immediate ms.invoke that will try to update zones.<zone>.dataNodes key. In > fact, we should defer state recalculation for some time specified by the user > in order to accumulate contiguous topology events. Please check following > example for more details: > |-1|start Node A; > start Node B; > start Node C; > CREATE ZONE zone1 WITH DATA_NODES_AUTO_ADJUST_{*}SCALE_UP{*} = 300; > CREATE TABLE Accounts … WITH PRIMARY_ZONE = zone1 |User starts three Ignite > nodes A, B, C and creates table Accounts specifying scale up auto adjust > timeout as 300 seconds. Accounts table is created on current topology, > meaning that <Transaction>.dataNodes = [A,B,C]| > |0|start Node D -> > Node D join/validation -> > D enters logical topology -> > logicalTopology.onNodeAdded(Node D) -> > scale_up_auto_adjust(300) timer is > scheduled for the <Accounts> table.|At time 0 seconds the user starts one > more Ignite node D, that joins the cluster. On entering logical topology the > onNodeAdded event is fired. This event schedules a timer of 300 seconds for > table Accounts after which the dataNodes of that table transitively through > the distribution zone will be recalculated from [A,B,C] to [A,B,C,D] > > | > |250|start Node E -> > scale_up_auto_adjust(300) is > {*}re{*}scheduled for the <Accounts> table.|At 250 seconds one more node > is added, that action reschedules scale_up_auto_adjust timer for another 300 > seconds.| > |550|scale_up_auto_adjust fired -> > set table.<Accounts>.dataNodes = > [NodeA, NodeB, NodeC, Node D, Node E]|At 550 seconds scale_up_time is > fired, that leads to <Transaction>dataNodes recalculation by attaching the > nodes that were added to logical topology - Nodes D and E in the given > example.| > |600|start Node F -> > <Accounts> table schedules > scale_up_auto_adjust(300);|At 600 seconds one more node is added, there > are no active scale_up_auto_adjust timers, so given events schedules new one.| > Thus it's required to modify ms topology handler in a way that it should > schedule or re-schedule a timer that will eventually call > ms.invoke(dataNodes). > h3. Definition of Done > * DataNodes recalculation is delayed for dataNodesAutoAdjustScaleUp value. > * In case of new scale up toplogy event, existing scale up timers should be > re-scheduled. > h3. Implemention Notes > As usual, pretty straight forward, ScheduledExecutorService with proper > naming should be introduced. Busy locks and proper scheduler stopping > required. -- This message was sent by Atlassian Jira (v8.20.10#820010)