Todd Lipcon has posted comments on this change. ( )

Change subject: KUDU-2343. java: properly reconnect to new leader master after 

Patch Set 1:

(1 comment)
Commit Message:
PS1, Line 10: We don't currently use the
            : master UUIDs in the Java client, so the connections to all 
masters were
            : getting conflated in the cache.
> Just passing through, but can you show me where this happens? I dug around
In typical java-client form, we have multiple ways where these rpc proxies get 
created. newMasterRpcProxy is only used in the 'connectToMasters' function, 
which is only used when we first connect to the cluster.

After we locate a master leader, we make a 'fake' GetTableLocationsResponsePB 
in ConnectToClusterResponse.getAsTableLocations(). We don't fill in the UUID 
field there.

I suppose filling in that with the master's UUID would have been an alternate 
way to fix this, rather than caching based on IP/port. However I think the 
ip/port cache makes more sense anyway in the case that a server re-registers on 
a different IP/port. (currently we have some server-side deficiencies that 
prevent that, but we shouldn't compound it with client-side issues)

To view, visit
To unsubscribe, visit

Gerrit-Project: kudu
Gerrit-Branch: master
Gerrit-MessageType: comment
Gerrit-Change-Id: I36f96c6712800e398ed46887d97d4b09fd993b04
Gerrit-Change-Number: 9612
Gerrit-PatchSet: 1
Gerrit-Owner: Todd Lipcon <>
Gerrit-Reviewer: Adar Dembo <>
Gerrit-Reviewer: Alexey Serbin <>
Gerrit-Reviewer: Anonymous Coward #314
Gerrit-Reviewer: Kudu Jenkins
Gerrit-Reviewer: Todd Lipcon <>
Gerrit-Comment-Date: Tue, 13 Mar 2018 21:07:18 +0000
Gerrit-HasComments: Yes

Reply via email to