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 61C37111E9 for ; Thu, 27 Mar 2014 06:56:37 +0000 (UTC) Received: (qmail 79815 invoked by uid 500); 27 Mar 2014 06:56:21 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 79543 invoked by uid 500); 27 Mar 2014 06:56:19 -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 79339 invoked by uid 99); 27 Mar 2014 06:56:17 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 27 Mar 2014 06:56:17 +0000 Date: Thu, 27 Mar 2014 06:56:17 +0000 (UTC) From: "Anoop Sam John (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Updated] (HBASE-10844) Coprocessor failure during batchmutation leaves the memstore datastructs in an inconsistent state 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-10844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anoop Sam John updated HBASE-10844: ----------------------------------- Fix Version/s: 0.94.19 > Coprocessor failure during batchmutation leaves the memstore datastructs in an inconsistent state > ------------------------------------------------------------------------------------------------- > > Key: HBASE-10844 > URL: https://issues.apache.org/jira/browse/HBASE-10844 > Project: HBase > Issue Type: Bug > Components: regionserver > Reporter: Devaraj Das > Assignee: Devaraj Das > Fix For: 0.99.0, 0.94.19, 0.98.2, 0.96.3 > > Attachments: 10844-1.txt > > > Observed this in the testing with Phoenix. The test in Phoenix - MutableIndexFailureIT deliberately fails the batchmutation call via the installed coprocessor. But the update is not rolled back. That leaves the memstore inconsistent. In particular, I observed that getFlushableSize is updated before the coprocessor was called but the update is not rolled back. When the region is being closed at some later point, the assert introduced in HBASE-10514 in the HRegion.doClose() causes the RegionServer to shutdown abnormally. -- This message was sent by Atlassian JIRA (v6.2#6252)