Mike Percy has posted comments on this change. Change subject: KUDU-871 (part 2). Make ConsensusMetadata thread-safe ......................................................................
Patch Set 1: > I haven't looked at the implementation here yet but I'm wondering > whether this may have potential performance impact. > > In particular, we would hold this lock while flushing/fsyncing new > ConsensusMetadata to disk. Are there code paths that previously > would not block but now block? Or were we always previously > protected by the ReplicaState lock, and now we're protected by the > ConsensusMeta lock? No, they are the same. I don't think there will be much of a performance impact because the vast majority of the time we will be acquiring an uncontended futex due to holding the ReplicaState lock to do things like get the current term in RaftConsensus / ReplicaState. > Regarding the above blocking (which is already problematic) -- does > this get us closer or farther away from an end state where the > cmeta is synchronized using an RWCLock? It would be great to allow > read-only callers to continue to read while an fsync is going on, > for example. I like this idea but I hadn't factored it in when writing this. I don't think it really helps or hurts us from the perspective of doing that. However it's likely we'd need a significant refactor of ReplicaState to do that (which we should do anyway). -- To view, visit http://gerrit.cloudera.org:8080/6958 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-MessageType: comment Gerrit-Change-Id: Id2c70605c0593e55486184705ea448dcb4bef2d7 Gerrit-PatchSet: 1 Gerrit-Project: kudu Gerrit-Branch: master Gerrit-Owner: Mike Percy <mpe...@apache.org> Gerrit-Reviewer: David Ribeiro Alves <davidral...@gmail.com> Gerrit-Reviewer: Kudu Jenkins Gerrit-Reviewer: Mike Percy <mpe...@apache.org> Gerrit-Reviewer: Tidy Bot Gerrit-Reviewer: Todd Lipcon <t...@apache.org> Gerrit-HasComments: No
