[jira] [Commented] (IGNITE-18026) Rework HLC propagation in parts related to Raft

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

    [ https://issues.apache.org/jira/browse/IGNITE-18026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17655119#comment-17655119 ] 

Denis Chudov commented on IGNITE-18026:
---------------------------------------

As it appears that user actually has no ability to add custom code that propagates some data from replicas to leader inside of raft group during replication, we should leave HLC propagation as is. The changes affect only safe time propagation.
[~vpyatkov] could you pls review the changes?

> Rework HLC propagation in parts related to Raft
> -----------------------------------------------
>
>                 Key: IGNITE-18026
>                 URL: https://issues.apache.org/jira/browse/IGNITE-18026
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Denis Chudov
>            Assignee: Denis Chudov
>            Priority: Major
>              Labels: ignite-3
>
> *Motivation:*
> As for now, HLC propagates via replica messages and Raft appendEntries messages. The latter required changes in jraft code which was done under IGNITE-17221 . Replica safe time (see IGNITE-17263 ) also uses HLC timestamps coming from leader, but these timestamps should be applied only on commiting index, so the whole mechanism consists of two steps: creating safe time candidate on processing of appendEntries request, and appying it on index commit. 
> All of this have grown up into significant amount of invasive code in jraft which is not related to Raft protocol itself. It can be reworked by moving the logic related to HLC and safe time propagation to ignite state machine listener working on top of Raft.
> *Definition of done:*
> There is no code related to HLC and safe time left in ignite-raft module.
> *Implementation notes:*
> Raft write commands can be enriched with HybridTimestamps. Idle HLC adjustment could be done using SafeTimeSyncCommand (it should be renamed in this case). Safe time candidates will no longer be needed.



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