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 6C350200D3E for ; Thu, 16 Nov 2017 19:12:04 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 6A88A160BEA; Thu, 16 Nov 2017 18:12:04 +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 B011B1609EF for ; Thu, 16 Nov 2017 19:12:03 +0100 (CET) Received: (qmail 43907 invoked by uid 500); 16 Nov 2017 18:12:02 -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 43894 invoked by uid 99); 16 Nov 2017 18:12:02 -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, 16 Nov 2017 18:12:02 +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 106DA180833 for ; Thu, 16 Nov 2017 18:12:02 +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 cIuf8mkaDVtJ for ; Thu, 16 Nov 2017 18:12:01 +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 1F6325FBEE for ; Thu, 16 Nov 2017 18:12: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 B298FE0295 for ; Thu, 16 Nov 2017 18:12: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 739B0240D2 for ; Thu, 16 Nov 2017 18:12:00 +0000 (UTC) Date: Thu, 16 Nov 2017 18:12:00 +0000 (UTC) From: "Umesh Agashe (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-18703) Inconsistent behavior for preBatchMutate in doMiniBatchMutate and processRowsWithLocks MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Thu, 16 Nov 2017 18:12:04 -0000 [ https://issues.apache.org/jira/browse/HBASE-18703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16255713#comment-16255713 ] Umesh Agashe commented on HBASE-18703: -------------------------------------- [~stack], thats true. Write paths are unified so there are no inconsistencies. This issue is essentially done. There are a couple of JIRAs that are left but can be worked upon after marking this closed. > Inconsistent behavior for preBatchMutate in doMiniBatchMutate and processRowsWithLocks > -------------------------------------------------------------------------------------- > > Key: HBASE-18703 > URL: https://issues.apache.org/jira/browse/HBASE-18703 > Project: HBase > Issue Type: Bug > Components: Coprocessors > Reporter: Duo Zhang > Assignee: Umesh Agashe > Priority: Critical > Fix For: 2.0.0-beta-1 > > Attachments: hbase-18703.master.001.patch, hbase-18703.master.002.patch, hbase-18703.master.003.patch, hbase-18703.master.004.patch, hbase-18703.master.005.patch, hbase-18703.master.005.patch, hbase-18703.master.005.patch, hbase-18703.master.006.patch, hbase-18703.master.007.patch > > > In doMiniBatchMutate, the preBatchMutate is called before building WAL, but in processRowsWithLocks, we suggest the RowProcessor implementation to build WAL in process method, which is ahead of preBatchMutate. > If a CP modifies the mutations, especially if it removes some cells from the mutations, then the behavior of processRowsWithLocks is broken. The changes applied to memstore and WAL will be different. And there is no way to remove entries from a WALEdit through CP. -- This message was sent by Atlassian JIRA (v6.4.14#64029)