Page Speed Optimization Libraries
1.13.35.1
|
#include "request_result_rpc_client.h"
Public Types | |
typedef ::grpc::ClientAsyncReaderWriterInterface < RequestT, ResponseT > | ReaderWriter |
Public Member Functions | |
RequestResultRpcClient (::grpc::CompletionQueue *queue, ThreadSystem *thread_system, MessageHandler *handler, CallbackT *callback) | |
virtual | ~RequestResultRpcClient () |
void | Start (grpc::CentralControllerRpcService::StubInterface *stub) |
Actually start the RPC by having the client call RequestFoo on the stub. | |
void | SendResultToServer (const RequestT &response) |
This is intended for use as the Context for a subclass of CentralControllerCallback (like ExpensiveOperationCallback or ScheduleRewriteCallback). Unfortunately it can't literally be the implementation of the Context due to double-inheritance, instead you probably want to put a subclass of this inside the Context and delegate to it. See ExpensiveOperationRpcContext for an example of this.
Subclassers probably should call Start() right after they create an instace of this. Start() will trigger a series of gRPC calls to the server and eventually call either Run or Cancel on the callback supplied to the constructor. If Run is called, do your work and then call SendResultToServer() to let it know you are done. If Cancel() is called, do not do the work.
|
inlinevirtual |
The child's destructor should probably call SendResultToServerIfActive to ensure proper cleanup happens. This isn't strictly required as the server will notice the hangup and handle it gracefully, but it may log errors in the process.
|
inline |
Call this once your client has completed their work, ie: they call something like Done(), or at context destruction. You may call this method as many times as you like, but only the first one will actually do anything.
Detach the rpc context stuff and kick off the last Write() to the server to let it know we're done. We do this "detached" because it's very common that this method is invoked through the destructor of the context, which shouldn't block. The AsyncCleanup callback just makes sure the message was sent to the server and logs an error if not.