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:
PS1, Line 9: possiblity
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
PS1, Line 1409: send
Line 1498: // TODO: Handle the situation when multiple in-flight RPCs are
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
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,
To view, visit http://gerrit.cloudera.org:8080/4570
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings
Gerrit-Owner: Jean-Daniel Cryans <jdcry...@apache.org>
Gerrit-Reviewer: Adar Dembo <a...@cloudera.com>
Gerrit-Reviewer: Dan Burkert <d...@cloudera.com>