You are viewing a plain text version of this content. The canonical link for it is here.
Posted to yarn-issues@hadoop.apache.org by "Hitesh Shah (JIRA)" <ji...@apache.org> on 2013/03/05 02:38:11 UTC

[jira] [Commented] (YARN-449) MRAppMaster classpath not set properly for unit tests in downstream projects

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

Hitesh Shah commented on YARN-449:
----------------------------------

This probably will work for a short term until the internal implementation of MiniYarnCluster or any other minicluster for that matter introduces a new config property that it needs/refers to. 

Looking at the hbase tests, it seems like that instead of using the config object returned by the MiniMRCluster and building on top of it, it tries to do some form of a union between 2 confs. In such cases, chances of missing some internal settings are always likely. I believe there was an earlier fix to set the framework.name to 'yarn' to solve something similar to the current problem when hbase starting running tests against 0.23.

[~tedyu@apache.org], do you have any comments on the above? Is it possible to change the base test class for hbase unit tests to build upon the config provided by the mini cluster? Any reason for not doing so? 
                
> MRAppMaster classpath not set properly for unit tests in downstream projects
> ----------------------------------------------------------------------------
>
>                 Key: YARN-449
>                 URL: https://issues.apache.org/jira/browse/YARN-449
>             Project: Hadoop YARN
>          Issue Type: Bug
>    Affects Versions: 2.0.3-alpha
>            Reporter: Siddharth Seth
>            Priority: Blocker
>         Attachments: hbase-TestHFileOutputFormat-wip.txt
>
>
> Post YARN-429, unit tests for HBase continue to fail since the classpath for the MRAppMaster is not being set correctly.
> Reverting YARN-129 may fix this, but I'm not sure that's the correct solution. My guess is, as Alexandro pointed out in YARN-129, maven classloader magic is messing up java.class.path.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira