hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Haibo Chen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-4985) Refactor the coprocessor code & other definition classes into independent packages
Date Thu, 09 Feb 2017 17:57:41 GMT

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

Haibo Chen commented on YARN-4985:

The dependency is not mainly because all tests are in the hbase-server module as they are
now, but because FlowScanner needs to reference FlowRun table schema classes. If we were to
extract another module that only includes table/column definitions, we can avoid the dependency
from hbase-server on hbase-client. But hbase-client code seems quite coupled to the table
schema code due to current code implementation (read & write methods are defined within
the Table/Column classes).  I will try to break the current hbase-client module in my patch
into hbase-schema and hbase-client. This way, we should not have the undesirable dependency
any more. 

That said, I think my previous concern about loading coprocessor from HDFS is still valid,
since we will still have hbase-server depend on hbase-schema.

> Refactor the coprocessor code & other definition classes into independent packages
> ----------------------------------------------------------------------------------
>                 Key: YARN-4985
>                 URL: https://issues.apache.org/jira/browse/YARN-4985
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: timelineserver
>            Reporter: Vrushali C
>            Assignee: Haibo Chen
>              Labels: YARN-5355
>         Attachments: YARN-4985-YARN-5355.prelim.patch
> As part of the coprocessor deployment, we have realized that it will be much cleaner
to have the coprocessor code sit in a package which does not depend on hadoop-yarn-server
classes. It only needs hbase and other util classes.
> These util classes and tag definition related classes can be refactored into their own
independent "definition" class package so that making changes to coprocessor code, upgrading
hbase, deploying hbase on a different hadoop version cluster etc all becomes operationally
much easier and less error prone to having different library jars etc.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: yarn-issues-unsubscribe@hadoop.apache.org
For additional commands, e-mail: yarn-issues-help@hadoop.apache.org

View raw message