[
https://issues.apache.org/jira/browse/HBASE-13907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15064084#comment-15064084
]
Sean Busbey commented on HBASE-13907:
-------------------------------------
+1
> 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-v6.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)
