Todd Lipcon has posted comments on this change.

Change subject: Integrate the request tracker with the client

Patch Set 8:

Commit Message:

Line 15: any specific tests.
it's not possible to use RetriableRpc within rpc_stub-test to test the client 
File src/kudu/client/

Line 194:            const scoped_refptr<RequestTracker>& request_tracker,
what about storing this in the Batcher? or grabbing it via 
batcher->client->data->request_tracker as necessary? seems like an unnecessary 
extra parameter (and refcount incr/decr)
File src/kudu/client/

Line 72: using rpc::RequestTracker;
spurious changes in this file?
File src/kudu/client/client-internal.h:

Line 27: #include "kudu/rpc/request_tracker.h"
can be a forward decl, no?
File src/kudu/client/meta_cache.h:

Line 34: #include "kudu/rpc/request_tracker.h"
File src/kudu/rpc/retriable_rpc.h:

Line 125:     // in flight, so we retry with a delay.
I think this merits a warning.

Line 193:     request_id->set_first_incomplete_seq_no(internal::NO_SEQ_NO);
why not just leave it unset in the PB?

Line 210:   request_tracker_->RpcCompleted(sequence_number_);
nit: mid-comment
File src/kudu/rpc/

Line 103:   return *request_id_.get();
nit: I think you dont need .get()
File src/kudu/rpc/rpc_controller.h:

Line 114:   const RequestIdPB& request_id() const;
I think this is somewhat error prone - IIRC the RPC layer "steals" the request 
ID out of the RpcController at send time, no? Seems like it's worth a doc 
comment that these are not accessible after an RPC has been sent. And maybe a 
DCHECK like some of the other accessors have?

To view, visit
To unsubscribe, visit

Gerrit-MessageType: comment
Gerrit-Change-Id: I94207c294452fcbdb3a7901fdb702674d47553ee
Gerrit-PatchSet: 8
Gerrit-Project: kudu
Gerrit-Branch: master
Gerrit-Owner: David Ribeiro Alves <>
Gerrit-Reviewer: David Ribeiro Alves <>
Gerrit-Reviewer: Kudu Jenkins
Gerrit-Reviewer: Todd Lipcon <>
Gerrit-HasComments: Yes

Reply via email to