eos-dom-akka is not panning out due to multiple reasons:
- poor transition performance: chasing-the-leader CSIT has noticeable performance drop
- Akka itself has changed licensing and we want to move away
We used to have an implementation based on sal-distrubuted-datastore, which, at the end of the day, is the wrong layer to integrate on.
Create eos-dom-akka-raft, which will provide eos-dom-api based on sal-akka-raft, replicating the appropriate state information.
The new component needs to have two aspects:
- EosRaftActor, which runs on every one and dynamically forms a cluster
- implementation of DOMEntityOwnershipService hosted by the EosRaftActor
What we want to achieve is an omni-present, majority-election-constrolled (hence sal-akka-raft), DOMEntityOwnershipService.
The implementation is split in the middle:
- registration of candidates pushes info to master
- activation of candidates is replicated from master