https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/CONTROLLER-1513 controller <p>In our current implementation, RaftActor is an abstract class, which defines callbacks to its subclasses &#8211; one of which is the Shard.</p> <p>This separation is not quite aligned with how services are decomposed in Akka and it creates tight coupling between the two components. That coupling is used for three things:</p> <ul class="alternate" type="square"> <li>RAFT state synchronization (i.e. RaftActor.isLeader())</li> <li>data persistence, which is currently synchronous</li> <li>shutdown synchronization</li> </ul> <p>The first need can easily be satisfied by massaging between Shard and RaftActor. The second one is stickier, but as it turns out we want to make Shard persistence asynchronous anyway, hence it can be turned into messaging between parent and child actors. The third one can easily be solved by having Shard as the parent process, which requests handoff and shuts RaftActor (child) down once the handoff is completed.</p> <p>Operating System: All<br/> Platform: All</p> CONTROLLER-1513

sal-akka-raft: separate Shard and RaftActor

Bug Resolved Won't Do Unassigned Robert Varga Mon, 25 Apr 2016 13:31:44 +0000 Tue, 25 Jul 2023 08:24:09 +0000 Thu, 18 May 2017 14:16:14 +0000 clustering 0 1 <p>This will also fix a problem with Shard.applyState(): currently Shard.applyState() is called via an internal RaftActor message (ApplyState), which is enqueue on the shared actor.</p> <p>This holds information which is only accurate for as long as Shard remains a leader, but since the message is enqueued on the same mailbox as RaftRPCs are, by the time this message is processed the role may have changed to follower.</p> <p>Separating the actors will have the effect of ApplyState being processed on Shard's queue, hence Shard will be observing the same (leader) state, simply because any state-changing messages will remain queued behind it.</p> <p>State is now applied synchronously to fix a consistency issue with persisted snapshots w.r.t lastAppliedIndex and the actual applied state. Separating the actors would likely re-introduce this issue. Regardless, there's no compelling reason to separate the actors anymore and it would add considerable complexity and risk (and possibly performance degradation). The reason the idea was first put forth was to alleviate follower election timeouts if the Shard leader was busy processing transaction messages. However, this issue was alleviated by having the follower check the reachability of the leader in the akka cluster state on election timeout. Also, we could always add an actor that just does a keep-alive (I had prototyped this prior to going with the reachability check).</p> Blocks CONTROLLER-1490 CONTROLLER-1512 Development External issue ID 5800 External issue URL Issue Type Rank 0|i02r1b: