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 <[email protected]> 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 姚驰 <[email protected]> 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
