[
https://issues.apache.org/jira/browse/HBASE-2937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12976563#action_12976563
]
Karthick Sankarachary commented on HBASE-2937:
----------------------------------------------
Hi Stack,
The interruptible client logic has been rewritten in such a way as to allow:
a) A timeout to be specified at the operation-level, which surrounds the block
of code that instantiates the server (proxy) as well as the invocation on that
proxy. Specifically, this was implemented by submitting the operation as a task
to a different thread and then waiting on its future object.
b) A timeout to be specified at the call-level, which only includes the
invocation on the server proxy object. Specifically, this was implemented by
setting a timeout on the wait method that the HBaseClient invokes on the call
object.
c) A retry logic to be specified at the call-level, which dictates how many
times, if at all, the call should be retried, in the event of a call-level
timeout.
For each of the above behaviors, corresponding configuration settings have been
made available (see TimeoutPolicy for details).
Last but not the least, a test case (viz. TestFromClientSide#testTimeouts) was
added which illustrates the various ways in which timeouts may be used.
I look forward to your comments.
Regards,
Karthick
> Facilitate Timeouts In HBase Client
> -----------------------------------
>
> Key: HBASE-2937
> URL: https://issues.apache.org/jira/browse/HBASE-2937
> Project: HBase
> Issue Type: New Feature
> Components: client
> Affects Versions: 0.89.20100621
> Reporter: Karthick Sankarachary
> Assignee: Karthick Sankarachary
> Priority: Critical
> Fix For: 0.92.0
>
> Attachments: HBASE-2937.patch, HBASE-2937.patch
>
>
> 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 will
> not return until a response (successful or otherwise) is received.
> In general, there are two ways to handle timeouts: (a) call the operation in
> 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
> read 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, the
> HBaseClient sets the socket timeout to the value of the "ipc.ping.interval"
> 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 every
> HTable operation, we chose to make it a property of HTable which effectively
> applies to every method that involves a remote operation.
> In order to propagate the timeout from HTable to HBaseClient, we replaced
> all occurrences of ServerCallable in HTable with an extension called
> ClientCallable, which sets the timeout on the region server interface, once
> it has been instantiated, through the HConnection object. The latter, in
> turn, asks HBaseRPC to pass that timeout to the corresponding Invoker, so
> that it may inject the timeout at the time the invocation is made on the
> region server proxy. Right before the request is sent to the server, we set
> the timeout specified by the client on the underlying socket.
> In conclusion, this patch will afford clients the option of performing an
> HBase operation until it completes or a specified timeout elapses. Note that
> a timeout of zero is interpreted as an infinite timeout.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
