Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 7 Oct 2016 18:37:20 +0000 (UTC)
From: "Andrew Purtell (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.13010517.1475860288000.766111.1475865440783@Atlassian.JIRA>
In-Reply-To: <JIRA.13010517.1475860288000@Atlassian.JIRA>
References: <JIRA.13010517.1475860288000@Atlassian.JIRA> <JIRA.13010517.1475860288595@arcas>
Subject: [jira] [Commented] (HBASE-16790) Need a better way to handler
 user's coprocessor error
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Fri, 07 Oct 2016 18:37:23 -0000


    [ https://issues.apache.org/jira/browse/HBASE-16790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15555898#comment-15555898 ] 

Andrew Purtell commented on HBASE-16790:
----------------------------------------

bq. User's bad coprocessor caused our hbase cluster down few times.
bq. Now we are going to set hbase.coprocessor.abortonerror to false to avoid them bring down whole cluster accidentally. But this is not encourage in production since it will cause inconsistent. Do we have better ways to handle this situation?

In general user code should not be running on the cluster as coprocessors. Coprocessors are meant for HBase developers and system architects / cluster operators to mix in additional functionality. Sandboxing is out of scope. That said:

bq. Seems we can disable table when load coprocessor throw exceptions.

Sure, this seems reasonable. 

> Need a better way to handler user's coprocessor error
> -----------------------------------------------------
>
>                 Key: HBASE-16790
>                 URL: https://issues.apache.org/jira/browse/HBASE-16790
>             Project: HBase
>          Issue Type: Bug
>            Reporter: yunjiong zhao
>         Attachments: HBASE-16790.master.001.patch
>
>
> User's bad coprocessor caused our hbase cluster down few times.
> Now we are going to set hbase.coprocessor.abortonerror to false to avoid them bring down whole cluster accidentally. But this is not encourage in production since it will cause inconsistent. Do we have better ways to handle this situation?
> Just few thoughts:
> 1. Instead of shutdown RegionServer, can we just disable the table which have  coprocessor error?
> 2. Can we give some of user privilege to add coprocessor only? We can't just set hbase.coprocessor.user.enabled=false, that will cause lots of works to operation the cluster. 
> 3. Can we add another step, wait for supper user approve before hbase dynamically load the  coprocessor?


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)