Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 61DB8200B5A for ; Thu, 4 Aug 2016 19:46:22 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 60626160AB1; Thu, 4 Aug 2016 17:46:22 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id A9736160A6A for ; Thu, 4 Aug 2016 19:46:21 +0200 (CEST) Received: (qmail 39142 invoked by uid 500); 4 Aug 2016 17:46:20 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 39085 invoked by uid 99); 4 Aug 2016 17:46:20 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Aug 2016 17:46:20 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id A948C2C0D63 for ; Thu, 4 Aug 2016 17:46:20 +0000 (UTC) Date: Thu, 4 Aug 2016 17:46:20 +0000 (UTC) From: "Andrew Purtell (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Comment Edited] (HBASE-15866) Split hbase.rpc.timeout into *.read.timeout and *.write.timeout MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Thu, 04 Aug 2016 17:46:22 -0000 [ https://issues.apache.org/jira/browse/HBASE-15866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15408192#comment-15408192 ] Andrew Purtell edited comment on HBASE-15866 at 8/4/16 5:45 PM: ---------------------------------------------------------------- [~vivek.koppuru@gmail.com] when I apply this patch to latest master, I have to fix up HConnectionTestingUtility to fix a compilation problem. When running tests, TestHCM#testRpcTimeout fails with this patch applied but not otherwise. I'm attaching a patch that includes the HConnectionTestingUtility change. Thinking about it, this change is also missing a unit test that verifies that read and writes will time out differently depending on these new settings. It should be trivial to clone TestHCM#testRpcTimeout and make a TestHCM#testWriteRpcTimeout. was (Author: apurtell): [~vivek.koppuru@gmail.com] when I apply this patch to latest master, I have to fix up HConnectionTestingUtility to fix a compilation problem. When running tests, TestHCM#testRpcTimeout fails with this patch applied but not otherwise. I'm attaching a patch that includes the HConnectionTestingUtility change. Let me look at the test failure, maybe it's an easy fix. > Split hbase.rpc.timeout into *.read.timeout and *.write.timeout > --------------------------------------------------------------- > > Key: HBASE-15866 > URL: https://issues.apache.org/jira/browse/HBASE-15866 > Project: HBase > Issue Type: Bug > Affects Versions: 2.0.0 > Reporter: Andrew Purtell > Assignee: Vivek Koppuru > Labels: newbie, patch > Fix For: 2.0.0 > > Attachments: HBASE-15866.patch, read-write-rpc-timeouts.patch > > > We have a single tunable for the RPC timeout interval - hbase.rpc.timeout. This is fine for the general case but there are use cases where it would be advantageous to set two separate timeouts for reads (gets, scans, perhaps with significant server side filtering - although the new scanner heartbeat feature mitigates where available) and mutations (fail fast under tight SLA, resubmit or take mitigating action). > I propose we refer to a configuration setting "hbase.rpc.read.timeout" when handling read operations and "hbase.rpc.write.timeout" when handling write operations. If those values are not set in the configuration, fall back to the value of "hbase.rpc.timeout" or its default. > So for example in HTable instead of one global timeout for each RPC (rpcTimeout), there would be a readRpcTimeout and writeRpcTimeout also set up in HTable#finishSetup. Then wherever we set up RPC with RpcRetryingCallerFactory#newCaller(int rpcTimeout) we pass in the read or write timeout depending on what the op is. > In general I don't like the idea of adding configuration parameters to our already heavyweight set, but I think the inability to control timeouts separately for reads and writes is an operational deficit. > See also PHOENIX-2916. -- This message was sent by Atlassian JIRA (v6.3.4#6332)