hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Devaraj Das" <d...@yahoo-inc.com>
Subject RE: RPC Client Functionality Questions
Date Mon, 16 Oct 2006 17:39:57 GMT

> -----Original Message-----
> From: Dennis Kubes [mailto:nutch-dev@dragonflymc.com]
> Sent: Monday, October 16, 2006 7:21 AM
> To: hadoop-dev@lucene.apache.org
> Subject: RPC Client Functionality Questions
> I have been going through the RPC framework and I wanted to confirm what
> I am seeing and ask a couple of questions.
>  From what I see the RPC framework returns dynamic proxy instances that
> use the Invoker as the InvocationHandler.  The Invoker uses a Client
> which uses a Connection and a Call to do the actual passing of the
> writable and returning of the result.  The networking happens inside of
> the Connection.  The Connection is pulled from a pool but initializes
> input and output streams and sockets on each call.  The Connection on
> sendParam method sends the Call over the network to the server and the
> socket input stream blocks waiting for a response back from the server.
> This is in a loop in the Connection thread and if the input stream read
> times out then it loops again and will block again waiting for a
> response.  This looks like this loop will happen indefinitely if nothing
> is returned from the server after the sendParam method is called.

Yes, that's true. 

> My first question is, am I reading this code correctly?  Is what is
> described above what is actually happening.
> When a call is finished the reading process the Connection object is in
> the pool if it didn't get removed by the ConnectionCuller thread for
> being idle to long.  When idle to long or an error occurs the should
> close flag on the Connection is set to true which causes it process to
> break out of the Connection processing loop in the run method and clean
> itself up eventually calling the close method.
> Again is what I am seeing correct?  If it is shouldn't we be closing the
> input streams in the close method or does closing the socket
> automatically handle that?

The streams should normally be closed (haven't looked at the source code
though). But since the Socket API documentation doesn't explicitly say this,
maybe we should be more explicit about it? 

> Dennis

View raw message