Adar Dembo has posted comments on this change.

Change subject: KUDU-456 Implement AUTO_FLUSH_BACKGROUND flush mode

Patch Set 22:

File src/kudu/client/client.h:

Line 1188:   /// The default and the minimum setting for this parameter is 2 
> Yes, technically the minimum could be 1.
OK. If it simplifies the implementation, let's keep the minimum at 2. We can 
always remove the restriction later.
File src/kudu/client/

PS22, Line 191:   Synchronizer s;
              :   KuduStatusMemberCallback<Synchronizer> ksmcb(&s, 
              :   NextBatcher(session, BATCHER_WATERMARK_NON_EMPTY, &ksmcb, 
              :   RETURN_NOT_OK(s.Wait());
> NextBatcher() not only flushes the current batcher, but it also allocates a
I wasn't asking about NextBatcher()'s wait; I was asking about s.Wait(). To 
help answer the question, here are all of the waits going on:

1. BLOCK in NextBatcher(). This ensures that a new batcher has become available.
2. s.Wait(). This ensures that the batcher we've flushed has finished flushing.
3. total_bytes_used_ == 0. This ensures that any other batchers in flight have 
finished flushing.

Do we need all of these? Naively, I think waiting for total_bytes_used_ to 
reach 0 is a superset of s.Wait(), no?

Moreover, don't we only need to get (and wait for) a new batcher on the next 
Apply()/ApplyAsync(), rather than here?

To view, visit
To unsubscribe, visit

Gerrit-MessageType: comment
Gerrit-Change-Id: I34905c30b3aad96f53cf7a1822b1cde6d25f33a8
Gerrit-PatchSet: 22
Gerrit-Project: kudu
Gerrit-Branch: master
Gerrit-Owner: Alexey Serbin <>
Gerrit-Reviewer: Adar Dembo <>
Gerrit-Reviewer: Alexey Serbin <>
Gerrit-Reviewer: Dan Burkert <>
Gerrit-Reviewer: Dinesh Bhat <>
Gerrit-Reviewer: Kudu Jenkins
Gerrit-Reviewer: Todd Lipcon <>
Gerrit-HasComments: Yes

Reply via email to