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 F3F06200B9A for ; Fri, 23 Sep 2016 05:28:23 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id F18C4160AE0; Fri, 23 Sep 2016 03:28:23 +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 446B5160AAD for ; Fri, 23 Sep 2016 05:28:23 +0200 (CEST) Received: (qmail 95845 invoked by uid 500); 23 Sep 2016 03:28:22 -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 95814 invoked by uid 99); 23 Sep 2016 03:28:22 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 23 Sep 2016 03:28:22 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id 2E0962C0D57 for ; Fri, 23 Sep 2016 03:28:22 +0000 (UTC) Date: Fri, 23 Sep 2016 03:28:22 +0000 (UTC) From: "Duo Zhang (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-15921) Add first AsyncTable impl and create TableImpl based on it MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Fri, 23 Sep 2016 03:28:24 -0000 [ https://issues.apache.org/jira/browse/HBASE-15921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15515258#comment-15515258 ] Duo Zhang commented on HBASE-15921: ----------------------------------- Let's talk about the retry and timeout logic. In general, I think we should only do retry at one place, which means, we always restart from the beginning. We can config different timeout values for different stages, but the actual timeout when executing the operation will also be limited by the whole operation timeout config. This could simplify our logic. For example, we do not need to implement retry logic in rpc(Yeah I have just removed the reconnect logic in NettyRpcConnection). And it is also much easier for us to implement the backoff logic. What do you think? [~stack] [~carp84] [~chenheng]. Thanks. > Add first AsyncTable impl and create TableImpl based on it > ---------------------------------------------------------- > > Key: HBASE-15921 > URL: https://issues.apache.org/jira/browse/HBASE-15921 > Project: HBase > Issue Type: Improvement > Affects Versions: 2.0.0 > Reporter: Jurriaan Mous > Assignee: Duo Zhang > Fix For: 2.0.0 > > Attachments: HBASE-15921-v2.patch, HBASE-15921.demo.patch, HBASE-15921.patch, HBASE-15921.v1.patch > > > First we create an AsyncTable interface with implementation without the Scan functionality. Those will land in a separate patch since they need a refactor of existing scans. > Also added is a new TableImpl to replace HTable. It uses the AsyncTableImpl internally and should be a bit faster because it does jump through less hoops to do ProtoBuf transportation. This way we can run all existing tests on the AsyncTableImpl to guarantee its quality. -- This message was sent by Atlassian JIRA (v6.3.4#6332)