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 70880200D15 for ; Thu, 21 Sep 2017 06:36:05 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 6EE2C1609E3; Thu, 21 Sep 2017 04:36:05 +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 B4D0B1609E2 for ; Thu, 21 Sep 2017 06:36:04 +0200 (CEST) Received: (qmail 83994 invoked by uid 500); 21 Sep 2017 04:36:03 -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 83982 invoked by uid 99); 21 Sep 2017 04:36:03 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 21 Sep 2017 04:36:03 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 244D41851DE for ; Thu, 21 Sep 2017 04:36:03 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -100.002 X-Spam-Level: X-Spam-Status: No, score=-100.002 tagged_above=-999 required=6.31 tests=[RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id RYFPRGkFB0u6 for ; Thu, 21 Sep 2017 04:36:02 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id 9AB9360D3F for ; Thu, 21 Sep 2017 04:36:01 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id D4AC6E0EE9 for ; Thu, 21 Sep 2017 04:36:00 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 352C8218FC for ; Thu, 21 Sep 2017 04:36:00 +0000 (UTC) Date: Thu, 21 Sep 2017 04:36:00 +0000 (UTC) From: "stack (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Assigned] (HBASE-11462) MetaTableAccessor shouldn't use ZooKeeeper MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Thu, 21 Sep 2017 04:36:05 -0000 [ https://issues.apache.org/jira/browse/HBASE-11462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stack reassigned HBASE-11462: ----------------------------- Assignee: Mikhail Antonov (was: ryan rawson) > MetaTableAccessor shouldn't use ZooKeeeper > ------------------------------------------ > > Key: HBASE-11462 > URL: https://issues.apache.org/jira/browse/HBASE-11462 > Project: HBase > Issue Type: Improvement > Components: Client, Zookeeper > Affects Versions: 2.0.0 > Reporter: Mikhail Antonov > Assignee: Mikhail Antonov > Fix For: 2.0.0 > > Attachments: HBASE-11462.v4.patch, HBASE-11462.v4.patch, HBASE-11462.v4.patch > > > After committing patch for HBASE-4495, there's an further improvement which can be made (discussed originally on review board to that jira). > We have MetaTableAccessor and MetaTableLocator classes. First one is used to access information stored in hbase:meta table. Second one is used to deal with ZooKeeper state to find out region server hosting hbase:meta, wait for it to become available and so on. > MetaTableAccessor, in turn, should only operate on the meta table content, so shouldn't need ZK. The only reason why MetaTableAccessor is using ZK - when callers request assignment information, they can request location of meta table itself, which we can't read from meta, so in that case MetaTableAccessor relays the call to MetaTableLocator. May be the solution here is to declare that clients of MetaTableAccessor shall not use it to work with meta table itself (not it's content). -- This message was sent by Atlassian JIRA (v6.4.14#64029)