[jira] [Updated] (IGNITE-23466) Rework DZM internals

["Denis Chudov (Jira)" <ji...@apache.org>]

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

Denis Chudov updated IGNITE-23466:
----------------------------------
    Summary: Rework DZM internals  (was: Refactor DZM internals)

> Rework DZM internals
> --------------------
>
>                 Key: IGNITE-23466
>                 URL: https://issues.apache.org/jira/browse/IGNITE-23466
>             Project: Ignite
>          Issue Type: Task
>            Reporter: Alexander Lapin
>            Assignee: Denis Chudov
>            Priority: Major
>              Labels: ignite-3, important
>             Fix For: 3.1
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> h3. Motivation
> In order to simply DistributionZone dataNodes processing and meet meta storage compaction requirements it's required not to use MG versioning. Generally following logic should be implemented.
>  * On topology event
>  ** Check whether we already have corresponding pending scaleUp/Down timer. If not: 
>  *** Serialised timer is written to MG synchronously. In timer's data bag it's expected to have
>  **** Awake/DataNodes atomic switch timestamp.
>  **** Data nodes to apply. 
>  *** Else:
>  **** Rewrite existing timer by updating Awake/DataNodes timestamp along with data nodes to apply. That should be done atomically in a way that calculated topology event timestamp is used while comparison with already existing awake one.
>  ** Timer is scheduled.
>  * On timer
>  ** Atomically remove the timer and set add new timestamp -> dataNodes entry in dataNodes map in MG and DZM volatile cache.
>  * On node restart:
>  ** restore corresponding volatile state from the MG.
>  * On filter change:
>  ** Immediately trigger on timer.
>  * On timeout adjustments
>  ** Rewrite existing timers if exists.
> There's a chance that topology and node attributes should also be internally versioned.
> h3. Definition of Done
>  * DZM manages dataNodes and related history internally in last MG key like Catalog does.
>  * New robust mechanic of atomic timers to dataNodes application is used. Details are described in Motivation section. 



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