Is it safe to set "hbase.coprocessor.abortonerror" to false on produce environment?

[姚驰 <ya...@163.com>]

  Hello, everyone. I'm new to coprocessor and I found that all regionservers would abort when I updated a wrong coprocessor. To get rid of this on produce environment, 
should I set "hbase.coprocessor.abortonerror" to false? I wonder if this option will cause any bad effect to my hbase service, please tell me if there is, thanks very much.

Re: Is it safe to set "hbase.coprocessor.abortonerror" to false on produce environment?

[Michael Segel <mi...@hotmail.com>]

Perfect example of why you really don’t want to allow user/homegrown coprocessors to run. 
If you’re running Ranger and a secure cluster… you have no choice you are running coprocessors. So you will want to shut down coprocessors that are not launched from your hbase-site.xml file.  (I forget the JIRA that Purtell fixed this in.) 

“Failing Fast is no way to run a production cluster…” ;-) 

> On Apr 30, 2015, at 1:23 PM, Gary Helmling <gh...@gmail.com> wrote:
> 
> The effect of setting this to false is that, if any of your coprocessors
> throw unexpected exceptions, instead of aborting, the region server will
> log an error and remove the coprocessor from the list of loaded
> coprocessors on the region / region server / master.
> 
> This allows HBase to continue running, but whether or not this is what you
> want depends largely on what your coprocessor is doing.  If your
> coprocessor is providing an essential service, such as access control, then
> simply unloading the coprocessor compromises that service, in this case
> security, which may be worse than simply failing fast.  Imagine a security
> exploit where you can trigger an error in the security coprocessor and then
> future requests can access any data with no access control being applied.
> Similarly, if your coprocessor is transforming data that is being written
> to a table (say updating secondary indexes), then unloading the coprocessor
> on an error would remove it from the write path of any future requests,
> allowing your data to become inconsistent.  Depending on what data you are
> storing and how it is being used, this may be a worse outcome than simply
> failing fast.
> 
> Since HBase cannot know how critical these situations are to you, and since
> coprocessors are a server side extension mechanism, HBase makes the
> conservative choice and defaults to failing fast in the face of coprocessor
> errors.
> 
> The "hbase.coprocessor.abortonerror" configuration certainly works in
> allowing HBase to continue running, but whether or not it is "safe" to use
> in a given situation depends on your use of HBase and coprocessors and
> understanding the consequences of the scenarios I outlined above.
> 
> 
> On Thu, Apr 30, 2015 at 8:04 AM 姚驰 <ya...@163.com> wrote:
> 
>>  Hello, everyone. I'm new to coprocessor and I found that all
>> regionservers would abort when I updated a wrong coprocessor. To get rid of
>> this on produce environment,
>> should I set "hbase.coprocessor.abortonerror" to false? I wonder if this
>> option will cause any bad effect to my hbase service, please tell me if
>> there is, thanks very much.

The opinions expressed here are mine, while they may reflect a cognitive thought, that is purely accidental. 
Use at your own risk. 
Michael Segel
michael_segel (AT) hotmail.com

Re: Is it safe to set "hbase.coprocessor.abortonerror" to false on produce environment?

[Gary Helmling <gh...@gmail.com>]

The effect of setting this to false is that, if any of your coprocessors
throw unexpected exceptions, instead of aborting, the region server will
log an error and remove the coprocessor from the list of loaded
coprocessors on the region / region server / master.

This allows HBase to continue running, but whether or not this is what you
want depends largely on what your coprocessor is doing.  If your
coprocessor is providing an essential service, such as access control, then
simply unloading the coprocessor compromises that service, in this case
security, which may be worse than simply failing fast.  Imagine a security
exploit where you can trigger an error in the security coprocessor and then
future requests can access any data with no access control being applied.
Similarly, if your coprocessor is transforming data that is being written
to a table (say updating secondary indexes), then unloading the coprocessor
on an error would remove it from the write path of any future requests,
allowing your data to become inconsistent.  Depending on what data you are
storing and how it is being used, this may be a worse outcome than simply
failing fast.

Since HBase cannot know how critical these situations are to you, and since
coprocessors are a server side extension mechanism, HBase makes the
conservative choice and defaults to failing fast in the face of coprocessor
errors.

The "hbase.coprocessor.abortonerror" configuration certainly works in
allowing HBase to continue running, but whether or not it is "safe" to use
in a given situation depends on your use of HBase and coprocessors and
understanding the consequences of the scenarios I outlined above.


On Thu, Apr 30, 2015 at 8:04 AM 姚驰 <ya...@163.com> wrote:

>   Hello, everyone. I'm new to coprocessor and I found that all
> regionservers would abort when I updated a wrong coprocessor. To get rid of
> this on produce environment,
> should I set "hbase.coprocessor.abortonerror" to false? I wonder if this
> option will cause any bad effect to my hbase service, please tell me if
> there is, thanks very much.