Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Browse files
Browse the repository at this point in the history
Huge refactoring: replace compaction by snapshotting
In recent discussions, we realized that the original motivation for the compaction implementation (i.e. deleting old IRC messages based on analyzing their dependencies) is no longer clear. Quite possibly, compaction just was the first idea that came to mind and we went with it. In the last couple of weeks (see the commit history), it became clear that the compaction approach is _really_ complex and complicated to get right. So, instead, with this commit, we serialize the IRCServer state into a single protocol buffer encoded message which is stored as a RobustState message as the first message of each snapshot. I.e., instead of re-applying thousands of messages to end up with a certain IRCServer state, we can now just deserialize the RobustState message. This is a backwards-compatible change, i.e. old snapshots can be read by new nodes just fine. However, once your nodes are upgraded and Raft took a new snapshot, you cannot downgrade anymore — the old versions won’t understand the new RobustState message. Further, you must update all nodes within a short period of time, ideally updating Followers before the Leader. That way, the chance of Raft transferring a snapshot from a new node to an older node is minimized. With compaction being gone, the behavior of the robustirc-canary tool changes slightly: instead of comparing all messages in the compaction window, it now compares all messages outside of the compaction window. The compaction window is boring to look at, since all messages are just deleted and replaced by the single snapshot message. The messages afterwards are more interesting to see if changes in the code caused a change in behavior. The robustirc-dump tool and the status page have been updated to display IRCServer state in text format (stripping privacy-sensitive information like connection passwords). We’ve decided to use protocol buffers for serialization instead of JSON because protocol buffers are way faster and will be used with gRPC anyway (see issue #132) and likely even before that to speed up node startup (see issue #131). fixes #108
- Loading branch information
1 parent
b813898
commit 2d3a623
Showing
29 changed files
with
1,552 additions
and
4,012 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.