[
https://issues.apache.org/jira/browse/HBASE-13907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15061011#comment-15061011
]
Sean Busbey commented on HBASE-13907:
-------------------------------------
{code}
+[WARNING]
+.Use Coprocessors At Your Own Risk
+====
+Coprocessors are an advanced feature of HBase and are intended to be used by
system
+developers only. Because coprocessor code runs directly on the RegionServer
and has
+direct access to your data, they introduce the risk of data corruption,
man-in-the-middle
+attacks, or other malicious data access. Currently, there is no mechanism to
prevent
+data corruption by coprocessors, though work is underway on
+link:https://issues.apache.org/jira/browse/HBASE-4047[HBASE-4047].
+====
{code}
I'd include a note about how there's also no resource isolation, so a totally
well intentioned but misbehaving coprocessor can severely degrade cluster
performance and stability.
> Document how to deploy a coprocessor
> ------------------------------------
>
> Key: HBASE-13907
> URL: https://issues.apache.org/jira/browse/HBASE-13907
> Project: HBase
> Issue Type: Bug
> Components: documentation
> Reporter: Misty Stanley-Jones
> Assignee: Misty Stanley-Jones
> Attachments: HBASE-13907-1.patch, HBASE-13907-2.patch,
> HBASE-13907-v3.patch, HBASE-13907-v4.patch, HBASE-13907-v5.patch,
> HBASE-13907.patch
>
>
> Capture this information:
> > Where are the dependencies located for these classes? Is there a path on
> > HDFS or local disk that dependencies need to be placed so that each
> > RegionServer has access to them?
> It is suggested to bundle them as a single jar so that RS can load the whole
> jar and resolve dependencies. If you are not able to do that, you need place
> the dependencies in regionservers class path so that they are loaded during
> RS startup. Do either of these options work for you? Btw, you can load the
> coprocessors/filters into path specified by hbase.dynamic.jars.dir [1], so
> that they are loaded dynamically by regionservers when the class is accessed
> (or you can place them in the RS class path too, so that they are loaded
> during RS JVM startup).
> > How would one deploy these using an automated system?
> > (puppet/chef/ansible/etc)
> You can probably use these tools to automate shipping the jars to above
> locations?
> > Tests our developers have done suggest that simply disabling a coprocessor,
> > replacing the jar with a different version, and enabling the coprocessor
> > again does not load the newest version. With that in mind how does one know
> > which version is currently deployed and enabled without resorting to
> > parsing `hbase shell` output or restarting hbase?
> Actually this is a design issue with current classloader. You can't reload a
> class in a JVM unless you delete all the current references to it. Since the
> current JVM (classloader) has reference to it, you can't overwrite it unless
> you kill the JVM, which is equivalent to restarting it. So you still have the
> older class loaded in place. For this to work, classloader design should be
> changed. If it works for you, you can rename the coprocessor class name and
> the new version of jar and RS loads it properly.
> > Where does logging go, and how does one access it? Does logging need to be
> > configured in a certain way?
> Can you please specify which logging you are referring to?
> > Where is a good location to place configuration files?
> Same as above, are these hbase configs or something else? If hbase configs,
> are these gateway configs/server side?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
