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 "Varun Saxena (JIRA)" <ji...@apache.org> on 2016/07/09 10:42:11 UTC
[jira] [Comment Edited] (YARN-5318)
TestRMAdminService#testRefreshNodesResourceWithFileSystemBasedConfigurationProvider
fails intermittently.
[ 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:41 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.
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.
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