Will Berkeley has posted comments on this change. ( http://gerrit.cloudera.org:8080/11923 )
Change subject: [location_awareness] Register client with location when connect to cluster ...................................................................... Patch Set 6: (8 comments) This first new PS is just a test run... no need for review until I submit another PS with an updated commit message. http://gerrit.cloudera.org:8080/#/c/11923/6/src/kudu/client/client-internal.cc File src/kudu/client/client-internal.cc: http://gerrit.cloudera.org:8080/#/c/11923/6/src/kudu/client/client-internal.cc@714 PS6, Line 714: location_ = connect_response.client_location(); > Does location_ need to be protected by leader_master_lock_? Why or why not? It needs to be protected by a lock- after a future patch, it may be used from one thread to select replicas to scan while the client is reconnecting to the cluster in another thread and being assigned a new location. leader_master_lock_ seems appropriate to reuse because it protects other things set when receiving a ConnectToMaster response from the leader master. http://gerrit.cloudera.org:8080/#/c/11923/6/src/kudu/master/master-test.cc File src/kudu/master/master-test.cc: http://gerrit.cloudera.org:8080/#/c/11923/6/src/kudu/master/master-test.cc@1626 PS6, Line 1626: TestConnectToMasterRegisterLocation > It would be nice to have a scenario to verify how the system behaves in cas Done http://gerrit.cloudera.org:8080/#/c/11923/6/src/kudu/master/master-test.cc@1635 PS6, Line 1635: ASSERT_OK(proxy_->ConnectToMaster(req, &resp, &rpc)); > Should also ASSERT that !resp.has_error. Done http://gerrit.cloudera.org:8080/#/c/11923/6/src/kudu/master/master_service.cc File src/kudu/master/master_service.cc: http://gerrit.cloudera.org:8080/#/c/11923/6/src/kudu/master/master_service.cc@536 PS6, Line 536: resp->set_client_location(location); > generic/paranoid nit: if GetClientLocation() didn't return Status::OK(), I Done http://gerrit.cloudera.org:8080/#/c/11923/6/src/kudu/master/ts_descriptor.h File src/kudu/master/ts_descriptor.h: http://gerrit.cloudera.org:8080/#/c/11923/6/src/kudu/master/ts_descriptor.h@182 PS6, Line 182: class ClientDescriptor { > Why is GetClientLocation stored in this class? Do you envision adding more I dropped this class and exposed GetLocationFromLocationMappingCommand as a function. This is a temporary state of affairs. A follow-up will factor that out into some kind of LocationAssigner class, probably with some caching policy. http://gerrit.cloudera.org:8080/#/c/11923/6/src/kudu/master/ts_descriptor.cc File src/kudu/master/ts_descriptor.cc: http://gerrit.cloudera.org:8080/#/c/11923/6/src/kudu/master/ts_descriptor.cc@410 PS6, Line 410: if (!location_mapping_cmd.empty()) { > style code/readability nit: prefer the 'return early' style here, i.e. N/A. Dropped this function in favor of (temporarily) exposing GetLocationFromLocationMappingCommand. http://gerrit.cloudera.org:8080/#/c/11923/6/src/kudu/master/ts_descriptor.cc@411 PS6, Line 411: string location_temp; > I don't think this indirection is needed; GetLocationFromLocationMappingCmd Ditto. http://gerrit.cloudera.org:8080/#/c/11923/6/src/kudu/master/ts_descriptor.cc@415 PS6, Line 415: if (s.ok()) { : *location = std::move(location_temp); : } else { : KLOG_EVERY_N_SECS(ERROR, 60) << Substitute( : "Unable to assign location to client: $0", : registration.rpc_addresses(0).host()); : return s; : } > the same style nit: prefer the 'return early' style Ditto. -- To view, visit http://gerrit.cloudera.org:8080/11923 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: kudu Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: I0efb327293d86168a30b05305f69d011ad15587a Gerrit-Change-Number: 11923 Gerrit-PatchSet: 6 Gerrit-Owner: Fengling Wang <fw...@cloudera.com> Gerrit-Reviewer: Adar Dembo <a...@cloudera.com> Gerrit-Reviewer: Alexey Serbin <aser...@cloudera.com> Gerrit-Reviewer: Fengling Wang <fw...@cloudera.com> Gerrit-Reviewer: Kudu Jenkins (120) Gerrit-Reviewer: Will Berkeley <wdberke...@gmail.com> Gerrit-Comment-Date: Tue, 18 Dec 2018 19:05:45 +0000 Gerrit-HasComments: Yes
