Hadoop RPC Analysis (i)--Client__java

[Hadoop RPC Call entry]In the basic framework of using Hadoop RPC, it is primarily through GetProxy to obtain a client proxy object through which RPC requests are sent to the server. GetProxy has multiple overloaded methods, which are ultimately called to the following function to implement (from Org.apache.hadoop.ipc.RPC) Public Static<T> protocolproxy<t> Getprotocolproxy (class<t> protocol, Long ClientVersion,                                  inetsocketaddress Addr,                                  Usergroupinformation Ticket ,                                  Configuration conf,                                   Socketfactory Factory,                                   intRpctimeout, Retrypolicy Connectionretrypolicy) throwsIOException { if(Usergroupinformation.issecurityenabled ())     {saslrpcserver.init (conf); } returnGetprotocolengine (protocol,conf). GetProxy (protocol, clientversion, addr, ticket, conf, Factory, Rpctimeout, Connec   Tionretrypolicy); }


On the server side, a build method is used to construct an object (from Org.apache.hadoop.ipc.RPC.Builder)/** the RPC server. * @throwsIOException On Error * @throwsHadoopillegalargumentexception when mandatory fields are not set */ PublicServerbuild () throwsIOException, Hadoopillegalargumentexception { if( This. conf = = NULL) { Throw NewHadoopillegalargumentexception ("Conf is not set"); } if( This. protocol = = NULL) { Throw NewHadoopillegalargumentexception ("Protocol is not set"); } if( This. Instance = = NULL) { Throw NewHadoopillegalargumentexception ("instance is not set"); } returnGetprotocolengine ( This. Protocol, This. conf). Getserver ( This. Protocol, This. instance, This. Bindaddress, This. Port, This. Numhandlers, This. Numreaders, This. Queuesizeperhandler, This. Verbose, This. conf, This. Secretmanager, This. Portrangeconfig); }
Through the two entrances above, the objects needed to make a remote call are generated on both the client and server side respectively.

Above the Getprotocolengine, is to obtain an RPC engine, the default is to use Writablerpcengine (the new version seems to change to Protobufrpcengine. , where you use Writablerpcengine for source tracking.
Here's a brief description of the tracking path:
Client: Writablerpcengine.getproxy ()---> invoker---> Client uses the dynamic proxy of JDK, Invoker implements the Invocationhandler interface, the realization of its Invoke method , which is implemented by calling the client's call method, the code is as follows
@Override PublicObjectinvoke (Object Proxy, Method method, object[] args) throwsThrowable { Longstarttime = 0; if(LOG. isdebugenabled ())       {starttime = Time.now (); }
Objectwritable value = (objectwritable) client. Call (RPC. Rpckind. Rpc_writable, NewInvocation (method, args), Remoteid); if(LOG. isdebugenabled ()) { LongCalltime = Time.now ()-starttime;       LOG. Debug ("Call:" + method.getname () + "" + calltime); }
Therefore, our understanding of the client will be mainly focused on the clients class.

Service side:Writablerpcengine.getserver ()---> Server
The new operation generates a server object, so our understanding of the service side will focus primarily on the server class.

[Hadoop RPC client: client]The idea of the client can be summarized as follows: The method information that is invoked is sent over the network to the server and waits for the return of the server. So in essence, RPC is a general network access to do encapsulation, resulting in a similar local invocation of the illusion. Here we will focus on the client's one RPC is what kind of process, and hope to find the corresponding implementation code.

The client-related classes are mainly for the following (all client internal classes) Client.connection--------A Connection object represents a connection channel between the server and the server, which provides the underlying channel information that is not specific to the calling business. exists as an underlying tool Client.call--------a call represents a remote procedure invocation that contains the request information for this remote procedure call, the call result return, and so on, as a remote procedure call business presence.
Due to the implementation of the underlying channel and the specific calling business, multiple invocation services can reuse the same underlying channel, and within the connection will maintain multiple current invocation services. The channel itself is business-independent, and there can be multiple parallel channels between the client and the server, and there will be a connection thread pool within clients.

First look at the Client's properties (from Org.apache.hadoop.ipc.Client)/** A counter for generating call IDs. */ Private Static FinalAtomicinteger Callidcounter = NewAtomicinteger (); Private Static FinalThreadlocal<integer> Callid = NewThreadlocal<integer> (); Private Static FinalThreadlocal<integer> RetryCount = NewThreadlocal<integer> (); PrivateHashtable<connectionid, connection>connections=   NewHashtable<connectionid, connection> (); Privateclass<? extends writable> Valueclass;  //class of Call values