hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hadoop QA (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-13907) Document how to deploy a coprocessor
Date Thu, 17 Dec 2015 02:47:46 GMT

    [ https://issues.apache.org/jira/browse/HBASE-13907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15061365#comment-15061365

Hadoop QA commented on HBASE-13907:

{color:red}-1 overall{color}.  Here are the results of testing the latest attachment 
  against master branch at commit 3dec8582f527e4e7e35280cd34c4928648290658.
  ATTACHMENT ID: 12778127

    {color:green}+1 @author{color}.  The patch does not contain any @author tags.

    {color:green}+0 tests included{color}.  The patch appears to be a documentation patch
that doesn't require tests.

    {color:green}+1 hadoop versions{color}. The patch compiles with all supported hadoop versions
(2.4.0 2.4.1 2.5.0 2.5.1 2.5.2 2.6.0 2.6.1 2.7.0 2.7.1)

    {color:green}+1 javac{color}.  The applied patch does not increase the total number of
javac compiler warnings.

    {color:green}+1 protoc{color}.  The applied patch does not increase the total number of
protoc compiler warnings.

    {color:red}-1 javadoc{color}.  The javadoc tool appears to have generated 1 warning messages.

    {color:green}+1 checkstyle{color}. The applied patch does not generate new checkstyle

    {color:green}+1 findbugs{color}.  The patch does not introduce any  new Findbugs (version
2.0.3) warnings.

    {color:green}+1 release audit{color}.  The applied patch does not increase the total number
of release audit warnings.

    {color:red}-1 lineLengths{color}.  The patch introduces the following lines longer than
+or it should implement the link:https://hbase.apache.org/devapidocs/org/apache/hadoop/hbase/Coprocessor.html[Coprocessor]
+such as link:http://hbase.apache.org/devapidocs/org/apache/hadoop/hbase/coprocessor/RegionObserver.html#prePut%28org.apache.hadoop.hbase.coprocessor.ObserverContext,%20org.apache.hadoop.hbase.client.Put,%20org.apache.hadoop.hbase.regionserver.wal.WALEdit,%20org.apache.hadoop.hbase.client.Durability%29[`prePut`].
Observers that happen just after an event override methods that start
+with a `post` prefix, such as link:http://hbase.apache.org/devapidocs/org/apache/hadoop/hbase/coprocessor/RegionObserver.html#postPut%28org.apache.hadoop.hbase.coprocessor.ObserverContext,%20org.apache.hadoop.hbase.client.Put,%20org.apache.hadoop.hbase.regionserver.wal.WALEdit,%20org.apache.hadoop.hbase.client.Durability%29[`postPut`].
+  a coprocessor to use the `prePut` method on `user` to insert a record into `user_daily_attendance`.
+  link:https://hbase.apache.org/devapidocs/org/apache/hadoop/hbase/coprocessor/RegionObserver.html[RegionObserver].
+  link:https://hbase.apache.org/devapidocs/org/apache/hadoop/hbase/coprocessor/BaseRegionObserver.html[BaseRegionObserver],
+  link:https://hbase.apache.org/devapidocs/org/apache/hadoop/hbase/coprocessor/RegionServerObserver.html[RegionServerObserver].

    {color:green}+1 site{color}.  The mvn post-site goal succeeds with this patch.

    {color:green}+1 core tests{color}.  The patch passed unit tests in .

    {color:green}+1 zombies{color}. No zombie tests found running at the end of the build.

Test results: https://builds.apache.org/job/PreCommit-HBASE-Build/16892//testReport/
Release Findbugs (version 2.0.3) 	warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/16892//artifact/patchprocess/newFindbugsWarnings.html
Checkstyle Errors: https://builds.apache.org/job/PreCommit-HBASE-Build/16892//artifact/patchprocess/checkstyle-aggregate.html

  Javadoc warnings: https://builds.apache.org/job/PreCommit-HBASE-Build/16892//artifact/patchprocess/patchJavadocWarnings.txt
Console output: https://builds.apache.org/job/PreCommit-HBASE-Build/16892//console

This message is automatically generated.

> 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

View raw message