Todd Lipcon 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?

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.

-- 
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 <[email protected]>
Gerrit-Reviewer: David Ribeiro Alves <[email protected]>
Gerrit-Reviewer: Kudu Jenkins
Gerrit-Reviewer: Tidy Bot
Gerrit-Reviewer: Todd Lipcon <[email protected]>
Gerrit-HasComments: No

Reply via email to