[ https://issues.apache.org/jira/browse/HBASE-13907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Misty Stanley-Jones updated HBASE-13907: ---------------------------------------- Status: Patch Available (was: Open) > 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)