Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1CC04110BC for ; Mon, 25 Aug 2014 09:10:59 +0000 (UTC) Received: (qmail 10776 invoked by uid 500); 25 Aug 2014 09:10:58 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 10737 invoked by uid 500); 25 Aug 2014 09:10:58 -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 10725 invoked by uid 99); 25 Aug 2014 09:10:58 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 25 Aug 2014 09:10:58 +0000 Date: Mon, 25 Aug 2014 09:10:58 +0000 (UTC) From: "Nicolas Liochon (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-11610) Enhance remote meta updates MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/HBASE-11610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14108920#comment-14108920 ] Nicolas Liochon commented on HBASE-11610: ----------------------------------------- It's great that v3 is both simpler and more efficient! I like the fact that all the complexity is put in a different class. MultiHConnection should be annotated private (nit)access to multiHConnection in #stop should be synchronized to be sure we see the last value. is MultiHConnection that useful? I see its size is defaulted to 1? have you compare the performances with greater values? Each Connection will come with a pool of 256 threads (there is HBASE-11590 to improve this a little), plus the one of MultiHConnection... As well, may be the TP in MultiHConnection should be configurable independently of the HConnection TP (i.e. we should have some thing like hbase.regionstatestore.meta.threads.max instead of hbase.hconnection.threads.max). But, may be the simplest is just to remove all the MultiHConnection (less code to maintain...) bq. return this.batchPool = tpe; (nit) This would be more readable with two lines. All these comments are more or less nit stuff. I like the patch. > Enhance remote meta updates > --------------------------- > > Key: HBASE-11610 > URL: https://issues.apache.org/jira/browse/HBASE-11610 > Project: HBase > Issue Type: Sub-task > Reporter: Jimmy Xiang > Assignee: Virag Kothari > Attachments: HBASE-11610.patch, HBASE-11610_2.patch, HBASE-11610_v3.patch > > > Currently, if the meta region is on a regionserver instead of the master, meta update is synchronized on one HTable instance. We should be able to do better. -- This message was sent by Atlassian JIRA (v6.2#6252)