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 8CEDF200C5A for ; Tue, 18 Apr 2017 20:41:52 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 8B820160BA1; Tue, 18 Apr 2017 18:41:52 +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 D35FA160B87 for ; Tue, 18 Apr 2017 20:41:51 +0200 (CEST) Received: (qmail 51261 invoked by uid 500); 18 Apr 2017 18:41:45 -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 51193 invoked by uid 99); 18 Apr 2017 18:41:44 -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; Tue, 18 Apr 2017 18:41:44 +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 0571A189A97 for ; Tue, 18 Apr 2017 18:41:44 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -99.202 X-Spam-Level: X-Spam-Status: No, score=-99.202 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id SSiZREGWqvft for ; Tue, 18 Apr 2017 18:41:43 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTP id 009DF60E16 for ; Tue, 18 Apr 2017 18:41:43 +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 67BEFE0907 for ; Tue, 18 Apr 2017 18:41:42 +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 C0BF821B56 for ; Tue, 18 Apr 2017 18:41:41 +0000 (UTC) Date: Tue, 18 Apr 2017 18:41:41 +0000 (UTC) From: "Abhishek Singh Chouhan (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-17937) Memstore size becomes negative in case of expensive postPut/Delete Coprocessor call MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Tue, 18 Apr 2017 18:41:52 -0000 [ https://issues.apache.org/jira/browse/HBASE-17937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15973257#comment-15973257 ] Abhishek Singh Chouhan commented on HBASE-17937: ------------------------------------------------ Have moved the size update to be just after step 5 and removed from finally as suggested by [~Apache9] since we don't do the rollback now with the chenged mvcc. [~lhofhansl] Agreed that this is a temporary condition till the time we return from the coprocessor call and proceed to the finally part, however if we have multiple such requests that seem to take a large amount of time or are stuck, like our observation recently we can possibly run into large negatives of memstore sizes (lets say -x mb) so the next flush will happen at x+memstore flush size which will take more time and so forth. > Memstore size becomes negative in case of expensive postPut/Delete Coprocessor call > ----------------------------------------------------------------------------------- > > Key: HBASE-17937 > URL: https://issues.apache.org/jira/browse/HBASE-17937 > Project: HBase > Issue Type: Bug > Affects Versions: 2.0.0, 1.3.1, 0.98.24 > Reporter: Abhishek Singh Chouhan > Assignee: Abhishek Singh Chouhan > Attachments: HBASE-17937.master.001.patch, HBASE-17937.master.002.patch > > > We ran into a situation where the memstore size became negative due to expensive postPut/Delete Coprocessor calls in doMiniBatchMutate. We update the memstore size in the finally block of doMiniBatchMutate, however a queued flush can be triggered during the coprocessor calls(if they are taking time eg. index updates) since we have released the locks and advanced mvcc at this point. The flush will turn the memstore size negative since the value subtracted is the actual value flushed from stores. The negative value impacts the future flushes amongst others that depend on memstore size. -- This message was sent by Atlassian JIRA (v6.3.15#6346)