These are chat archives for atomix/atomix
We are no longer monitoring this channel, please join Slack! https://join.slack.com/t/atomixio/shared_invite/enQtNDgzNjA5MjMyMDUxLTVmMThjZDcxZDE3ZmU4ZGYwZTc2MGJiYjVjMjFkOWMyNmVjYTc5YjExYTZiOWFjODlkYmE2MjNjYzZhNjU2MjY
AppendRequests from the leader and separate log threads, but none of those optimizations had any positive impact on performance because of the concurrency control it necessitated in the log. Because so much of the algorithm relies on strict order, a lot of the benefits of concurrency are subdued. Pipelining and flushing to disk on commits proved far more beneficial to performance than anything else.
Iteratorwould prevent almost all binary index searches (except when an append fails) on the leader.
onEventand the state machine
synchronizedmethods would have little to no impact on log management aside from the log compaction threads because of biased locking. The server thread should have no trouble getting locks. But what I didn't realize is that the log is also accessed for releasing entries from the state machine thread, and furthermore that because the state machine can release entries at arbitrary and unspecified points in the log at any given time, binary search becomes necessary for every entry after a segment is compacted. One interesting idea is that an entry's offset in a segment could be stored in the entry itself. That would preclude the need for an index lookup when releasing the entry. But log compaction still poses a challenge since offsets change after compaction. So, offsets could be updated in entries, but that would require tracking referenced entries in the log, and that's probably too great a task for little gain.