hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Dagaev" <michael.dag...@gmail.com>
Subject Re: Question on Single Connection Limitation
Date Thu, 25 Dec 2008 17:32:04 GMT
Hi, Stack

   Thank you for the answer.  I should have read the code before
starting this thread :)

Is it correct that the RPC client read/write to the socket in blocking mode ?
That is, if a client sends/receives a large buffer it will be blocked
until the entire buffer
will be sent/received.

Thank you for your cooperation,
M.

On Thu, Dec 25, 2008 at 12:33 AM, stack <stack@duboce.net> wrote:
> Michael Dagaev wrote:
>>
>> ...
>> How should it work ?
>> 0:02 C1 should release the connection after sending the request.
>> 0:02 C2 should grab it and send the request while C1 is waiting
>> and S1 is handling the request of C1.
>> ...
>>
>> Now the connection works more and that is how good RPC implementations
>> work.
>>
>
> This is how it works currently Michael.  RPC Client has one Connection for
> each target server.  This Connection is shared by all RPC Clients in current
> JVM.  Sending and receiving is synchronized.
>
> See the call method in the RPC Client class:
> http://svn.apache.org/viewvc/hadoop/hbase/trunk/src/java/org/apache/hadoop/hbase/ipc/HBaseClient.java?view=markup
>
> See how it gets a Connection appropriate to the address.  In base of the
> getConnection, a Call object is 'registered'.  We then send the request
> (sendParam -- see how it synchronizes on the out stream).
>
> There is a response processor that runs reading the in stream.  Results are
> identified by an id.  The id is used to figure which of the registered Calls
> the response is for.
>
> As is, I foresee issues if requests or responses take a long time to send or
> maybe, if cluster is small and uploader is single-process multithreaded.
>
> St.Ack
>

Mime
View raw message