-
Notifications
You must be signed in to change notification settings - Fork 9.2k
MAPREDUCE-7311. Clear filesystem statistics after tests in TestTaskProgressReporter #2500
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MAPREDUCE-7311. Clear filesystem statistics after tests in TestTaskProgressReporter #2500
Conversation
|
🎊 +1 overall
This message was automatically generated. |
aajisaka
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the test case fails before L327, the statistics is not cleared. Would you create an @After method and clear the statistics there? That way the statistics is alway cleared.
@aajisaka Good point. Updated the fix accordingly. Thanks! |
|
🎊 +1 overall
This message was automatically generated. |
aajisaka
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
|
Merged. Thank you @lzx404243 for stabilizing tests. |
…ogressReporter (#2500) Co-authored-by: Zhengxi Li <[email protected]> (cherry picked from commit 6187f76)
…ogressReporter (#2500) Co-authored-by: Zhengxi Li <[email protected]> (cherry picked from commit 6187f76)
…ogressReporter (apache#2500) Co-authored-by: Zhengxi Li <[email protected]>
The test
org.apache.hadoop.mapred.TestTaskProgressReporter.testBytesWrittenRespectingLimitis not idempotent and fails if run twice in the same JVM, because it pollutes state shared among tests. It may be good to clean this state pollution so that some other tests do not fail in the future due to the shared state polluted by this test.Details
Running
TestTaskProgressReporter.testBytesWrittenRespectingLimittwice would result in the second run failing with the following assertion:The root cause for this is that when
testBytesWrittenRespectingLimitwrites some bytes on the local file system, some counters are being incremented. The problem is that, after the test is done, the counter is not reset. With this polluted shared state, assumptions are broken, resulting in test failure in the second run.The fix is to invoke
FileSystem.clearStatistics()to reset the counter(among others statistics) when the test finishes.With the proposed fix, the test does not pollute the shared state (and passes when run twice in the same JVM).
Jira link: MAPREDUCE-7311