Todd Lipcon has posted comments on this change. ( http://gerrit.cloudera.org:8080/9612 )
Change subject: KUDU-2343. java: properly reconnect to new leader master after failover ...................................................................... Patch Set 1: (1 comment) http://gerrit.cloudera.org:8080/#/c/9612/1//COMMIT_MSG Commit Message: http://gerrit.cloudera.org:8080/#/c/9612/1//COMMIT_MSG@10 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 http://gerrit.cloudera.org:8080/9612 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: kudu Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: I36f96c6712800e398ed46887d97d4b09fd993b04 Gerrit-Change-Number: 9612 Gerrit-PatchSet: 1 Gerrit-Owner: Todd Lipcon <t...@apache.org> Gerrit-Reviewer: Adar Dembo <a...@cloudera.com> Gerrit-Reviewer: Alexey Serbin <aser...@cloudera.com> Gerrit-Reviewer: Anonymous Coward #314 Gerrit-Reviewer: Kudu Jenkins Gerrit-Reviewer: Todd Lipcon <t...@apache.org> Gerrit-Comment-Date: Tue, 13 Mar 2018 21:07:18 +0000 Gerrit-HasComments: Yes
