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 50FDC18816 for ; Wed, 6 Jan 2016 03:12:40 +0000 (UTC) Received: (qmail 59215 invoked by uid 500); 6 Jan 2016 03:12:40 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 59162 invoked by uid 500); 6 Jan 2016 03:12:40 -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 59123 invoked by uid 99); 6 Jan 2016 03:12:40 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Jan 2016 03:12:40 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id E8AB02C1F5D for ; Wed, 6 Jan 2016 03:12:39 +0000 (UTC) Date: Wed, 6 Jan 2016 03:12:39 +0000 (UTC) From: "Heng Chen (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-15071) Cleanup bypass semantic in MasterCoprocessorHost 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-15071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15084610#comment-15084610 ] Heng Chen commented on HBASE-15071: ----------------------------------- Sounds reasonable. Let me take it, OK? > Cleanup bypass semantic in MasterCoprocessorHost > ------------------------------------------------ > > Key: HBASE-15071 > URL: https://issues.apache.org/jira/browse/HBASE-15071 > Project: HBase > Issue Type: Task > Components: Coprocessors > Affects Versions: 2.0.0 > Reporter: stack > Priority: Blocker > > Lets decide on this one before we release 2.0.0. > A bunch of methods in MasterCoprocessorHost on the 'pre' step allow returning true which indicates the method invocation is not to proceed. > Not all 'pre' steps do this. Just some. > Seems a little arbitrary. > How we skip out if we are not proceed with the invocation is also a little arbitrary. > When a deleteColumn call is supposed to skip out, it returns a -1, a non-procId. If we are to skip a balance call, we log that CP said skip and then return false to indicate the balancer did not run (why?). Elsewhere we just exit silently. In createNamespace we used to exit silently but HBASE-14888 just changed it so we throw a BypassCoprocessorException instead... > Lets make them all work the same way. > (This issue comes of chat w/ Matteo) -- This message was sent by Atlassian JIRA (v6.3.4#6332)