hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Naganarasimha G R (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (YARN-3792) Test case failures in TestDistributedShell and some issue fixes related to ATSV2
Date Tue, 16 Jun 2015 07:42:01 GMT

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

Naganarasimha G R commented on YARN-3792:
-----------------------------------------


bq. I still see one test failing:
I had sufficiently tested in my laptop but still seems to be happening :(
bq. l.376: I don't really like the sleep call as it is not completely deterministic; could
there be a way to make this completely deterministic (using things like CountDownLatch, etc.)?
Test failing also is due to the fact that there is a race condition between the application
finished being published and test case checking this published event in the file. AFAIK using
CountDownLatch might not be possible as its happening asynchrously in the Mini YARN cluster
and the test case needs to wait till published event is written to the file. In the test case
once Application status(YarnApplicationState) and FinalApplicationStatus indicates the app
is over we are checking for the published events, even then as events are published through
dispatcher its not guranteed to be finished. Other approach i can think of is to make the
test sleep for 500 seconds 3~4 times or till the desired result is got (i think this is the
approach which is followed in most of the test cases which are highly async), thoughts ? I
am open for other approaches too :)

bq. l.71-75: Is this comment necessary here? I'm not sure if we want to add a generic comment
like this to a specific test...
Well atleast in my environment(latest ubuntu) even after JAVA_HOME was set properly in shell,
test cases when executed from eclipse were failing because of the JAVA_HOME was not availble
and it took a while for me to figure out doing this. Hence i thought it would be usefull information
for others who r testing for the first time, If you guys feel not necessary i can remove it.

bq. l.106: Are the checks for null necessary? I thought that the test name was populated by
junit and made available to test methods. Do things fail if we do not check for null?
yes its req, as mentioned earlier for ??{{TestDistributedShellWithNodeLabels.testDSShellWithNodeLabelExpression}}
was failing because method name rule will not set be set in TestDistributedShell.setupInternal??

Can take care of the remaining comments

> Test case failures in TestDistributedShell and some issue fixes related to ATSV2
> --------------------------------------------------------------------------------
>
>                 Key: YARN-3792
>                 URL: https://issues.apache.org/jira/browse/YARN-3792
>             Project: Hadoop YARN
>          Issue Type: Sub-task
>          Components: timelineserver
>            Reporter: Naganarasimha G R
>            Assignee: Naganarasimha G R
>         Attachments: YARN-3792-YARN-2928.001.patch
>
>
> # encountered [testcase failures|https://builds.apache.org/job/PreCommit-YARN-Build/8233/testReport/]
which was happening even without the patch modifications in YARN-3044
> TestDistributedShell.testDSShellWithoutDomainV2CustomizedFlow
> TestDistributedShell.testDSShellWithoutDomainV2DefaultFlow
> TestDistributedShellWithNodeLabels.testDSShellWithNodeLabelExpression
> # Remove unused {{enableATSV1}} in testDisstributedShell
> # container metrics needs to be published only for v2 test cases of testDisstributedShell
> # Nullpointer was thrown in TimelineClientImpl.constructResURI when Aux service was not
configured and {{TimelineClient.putObjects}} was getting invoked.
> # Race condition for the Application events to published and test case verification for
RM's ApplicationFinished Timeline Events
> # Application Tags for converted to lowercase in ApplicationSubmissionContextPBimpl,
hence RMTimelinecollector was not able to detect to custom flow details of the app



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message