Adar Dembo has posted comments on this change.

Change subject: [java client] Tight-ish loop in master lookups if a tablet 
doesn't have a leader

Patch Set 1:

Commit Message:

PS1, Line 9: possiblity
Nit: possibility

PS1, Line 19: 101
While we're at it, can we remove this upper bound? It's a completely arbitrary 
number and it doesn't make sense; only the deadline expiring should make us 
stop retrying.
File java/kudu-client/src/main/java/org/apache/kudu/client/

PS1, Line 1409: send
Nit: throw

Line 1498:     // TODO: Handle the situation when multiple in-flight RPCs are 
queued waiting
I know you just moved this comment, but I didn't really understand it 
originally either. What makes this situation special such that we need 
additional logic for it? What happens today when multiple RPCs are waiting to 
find out who the leader master is?

PS1, Line 1499: determine
Nit: determined

PS1, Line 50: "testDisconnect"
This means that if testDisconnect() fails and is retried by maven, it'll fail 
again because the testDisconnect table will already exist.

Until such a time that we clean up the mini cluster state after each test like 
the C++ tests, we need to retain the idiom of appending the time to the table 

Line 157:     KuduTable table = createTable("testNoLeader", basicSchema, 
Same here.

To view, visit
To unsubscribe, visit

Gerrit-MessageType: comment
Gerrit-Change-Id: Ibf2bd53b03551642e4d036d322e1e592b7c2cfec
Gerrit-PatchSet: 1
Gerrit-Project: kudu
Gerrit-Branch: master
Gerrit-Owner: Jean-Daniel Cryans <>
Gerrit-Reviewer: Adar Dembo <>
Gerrit-Reviewer: Dan Burkert <>
Gerrit-HasComments: Yes

Reply via email to