hadoop-yarn-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Varun Saxena (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (YARN-5318) TestRMAdminService#testRefreshNodesResourceWithFileSystemBasedConfigurationProvider fails intermittently.
Date Sat, 09 Jul 2016 10:43:10 GMT

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

Varun Saxena edited comment on YARN-5318 at 7/9/16 10:42 AM:
-------------------------------------------------------------

[~sandflee], 
bq. seems there is no granted that event is processed completely even if event queue is empty.
That's correct. Merely draining main RM Dispatcher queue wont lead to processing of scheduler
events sitting in the scheduler event queue. 
But for this specific test case, we check against resource value in RMNodeImpl and node events
are processed from the main RM Dispatcher, which will be drained. So, scheduler event processing
in this case is not required. The changed value we are checking against will get reflected
as soon as the node event is processed.
Correct me if I have missed something here.

However, in some test cases draining of scheduler dispatcher can be useful. We can add support
for in whichever JIRA we see the need. I guess when drainEvents was added in MockRM, it was
because there was use for only that and as we already had a DrainDispatcher, a subclass for
AsyncDispatcher, which is used for draining, it made such addition trivial.
For scheduler dispatcher though, AsyncDispatcher is not used so some additional code will
have to be added.


was (Author: varun_saxena):
[~sandflee], 
bq. seems there is no granted that event is processed completely even if event queue is empty.
That's correct. Merely draining main RM Dispatcher queue wont lead to processing of scheduler
events sitting in the scheduler event queue. 
But for this specific test case, we check against resource value in RMNodeImpl and node events
are processed from the main RM Dispatcher, which will be drained. So, scheduler event processing
in this case is not required. The changed value we are checking against will get reflected
as soon as the node event is processed.
Correct me if I have missed something here.

However, in some test cases draining of scheduler dispatcher can be useful. We can add support
for in whichever JIRA we see the need. I guess when drainEvents was added in MockRM, it was
because there was use for only that and as we already had a DrainDispatcher, a subclass for
AsyncDispatcher, which is used for draining, it made such addition trivial.

> TestRMAdminService#testRefreshNodesResourceWithFileSystemBasedConfigurationProvider fails
intermittently.
> ---------------------------------------------------------------------------------------------------------
>
>                 Key: YARN-5318
>                 URL: https://issues.apache.org/jira/browse/YARN-5318
>             Project: Hadoop YARN
>          Issue Type: Test
>            Reporter: sandflee
>            Assignee: Jun Gong
>            Priority: Minor
>             Fix For: 2.8.0
>
>         Attachments: YARN-5318.01.patch
>
>
> org.junit.ComparisonFailure: expected:<<memory:[4096, vCores:4]>> but was:<<memory:[5120,
vCores:5]>>
> 	at org.junit.Assert.assertEquals(Assert.java:115)
> 	at org.junit.Assert.assertEquals(Assert.java:144)
> 	at org.apache.hadoop.yarn.server.resourcemanager.TestRMAdminService.testRefreshNodesResourceWithFileSystemBasedConfigurationProvider(TestRMAdminService.java:238)
> https://builds.apache.org/job/PreCommit-YARN-Build/12204/testReport/org.apache.hadoop.yarn.server.resourcemanager.applicationsmanager/TestAMRestart/testAMRestartNotLostContainerCompleteMsg/



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

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


Mime
View raw message