Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: neutral (nike.apache.org: 184.73.217.71 is neither permitted nor
 denied by domain of karthick.sankarachary@gmail.com)
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Subject: Re: Review Request: HBase-2937 Facilitate Timeouts In HBase Client
From: "Karthick Sankarachary" <karthick.sankarachary@gmail.com>
To: jiraposter@review.hbase.org,
	"Karthick Sankarachary" <karthick.sankarachary@gmail.com>,
	dev@hbase.apache.org
Date: Mon, 30 Aug 2010 21:29:12 -0000
Message-ID: <20100830212912.31806.93767@ip-10-202-7-187.ec2.internal>
In-Reply-To: <20100830212831.31805.94718@ip-10-202-7-187.ec2.internal>
References: <20100830212831.31805.94718@ip-10-202-7-187.ec2.internal>


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://review.cloudera.org/r/747/
-----------------------------------------------------------

(Updated 2010-08-30 14:29:12.219496)


Review request for hbase.


Summary (updated)
-------

Currently, there is no way to force an operation on the HBase client (viz. =
HTable) to time out if a certain amount of time has elapsed. In other words=
, all invocations on the HTable class are veritable blocking calls, which w=
ill not return until a response (successful or otherwise) is received.

In general, there are two ways to handle timeouts: (a) call the operation i=
n a separate thread, until it returns a response or the wait on the thread =
times out and (b) have the underlying socket unblock the operation if the r=
ead times out. The downside of the former approach is that it consumes more=
 resources in terms of threads and callables.

Here, we describe a way to specify and handle timeouts on the HTable client=
, which relies on the latter approach (i.e., socket timeouts). Right now, t=
he HBaseClient sets the socket timeout to the value of the "ipc.ping.interv=
al" parameter, which is also how long it waits before pinging the server in=
 case of a failure. The goal is to allow clients to set that timeout on the=
 fly through HTable. Rather than adding an optional timeout argument to eve=
ry HTable operation, we chose to make it a property of HTable which effecti=
vely applies to every method that involves a remote operation.

In order to propagate the timeout from HTable to HBaseClient, we replaced a=
ll occurrences of ServerCallable in HTable with an extension called ClientC=
allable, which sets the timeout on the region server interface, once it has=
 been instantiated, through the HConnection object. The latter, in turn, as=
ks HBaseRPC to pass that timeout to the corresponding Invoker, so that it m=
ay inject the timeout at the time the invocation is made on the region serv=
er proxy. Right before the request is sent to the server, we set the timeou=
t specified by the client on the underlying socket.

In conclusion, this patch will afford clients the option of performing an H=
Base operation until it completes or a specified timeout elapses. Note that=
 a timeout of zero is interpreted as an infinite timeout.


This addresses bug HBASE-2937.
    http://issues.apache.org/jira/browse/HBASE-2937


Diffs
-----

  src/main/java/org/apache/hadoop/hbase/Timeout.java PRE-CREATION =

  src/main/java/org/apache/hadoop/hbase/client/ClientCallable.java PRE-CREA=
TION =

  src/main/java/org/apache/hadoop/hbase/client/HConnection.java 8b3b6a4 =

  src/main/java/org/apache/hadoop/hbase/client/HConnectionManager.java ac2b=
99c =

  src/main/java/org/apache/hadoop/hbase/client/HTable.java cd60eeb =

  src/main/java/org/apache/hadoop/hbase/ipc/HBaseClient.java 2b5eeb6 =

  src/main/java/org/apache/hadoop/hbase/ipc/HBaseRPC.java 9873172 =


Diff: http://review.cloudera.org/r/747/diff


Testing
-------


Thanks,

Karthick