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 4E373200BAD for ; Mon, 10 Oct 2016 09:25:22 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 4B5F7160AF6; Mon, 10 Oct 2016 07:25: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 BB435160AE1 for ; Mon, 10 Oct 2016 09:25:21 +0200 (CEST) Received: (qmail 22599 invoked by uid 500); 10 Oct 2016 07:25: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 22517 invoked by uid 99); 10 Oct 2016 07:25:20 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Oct 2016 07:25:20 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id 8C62A2C0088 for ; Mon, 10 Oct 2016 07:25:20 +0000 (UTC) Date: Mon, 10 Oct 2016 07:25:20 +0000 (UTC) From: "Anoop Sam John (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Created] (HBASE-16799) CP exposed Store should not expose unwanted APIs MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Mon, 10 Oct 2016 07:25:22 -0000 Anoop Sam John created HBASE-16799: -------------------------------------- Summary: CP exposed Store should not expose unwanted APIs Key: HBASE-16799 URL: https://issues.apache.org/jira/browse/HBASE-16799 Project: HBase Issue Type: Bug Reporter: Anoop Sam John Assignee: Anoop Sam John Fix For: 2.0.0 Store is exposed to CPs. The main use cases I can think of are getting store scanner and other getters which return different states like memstore size, max seqId etc. Those make sense. But we added many other APIs which changes the state of the memstore, bulk load files etc into this interface. Even an API which expose the memstore itself!. This allow adding mutations into memstore bypassing all steps in region. We track the memstore size per region level as well as globally. These only allow us to flush region at sizes and/or flush selected regions because of global heap pressure. Now if a CP get hold of store and/or memstore, it can add mutations with out knowledge of these size accounting and possibly OOME the RS. Similar way the bulk load related APIs. At HRegion level, there are steps done (WAL write etc) after the bulk load HFile on store. So bypassing these wont be correct. In this jira, plan is to remove all such leaked APIs from Store. They are called from HRegion and we can type cast to HStore to call them. -- This message was sent by Atlassian JIRA (v6.3.4#6332)