[
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-unsubscr...@hadoop.apache.org
For additional commands, e-mail: yarn-issues-h...@hadoop.apache.org
