-
Notifications
You must be signed in to change notification settings - Fork 8.9k
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
YARN-11305. Fix TestLogAggregationService#testLocalFileDeletionAfterUpload Failed After YARN-11241(#4703). #4893
Conversation
…pload Failed After YARN-11241(apache#4703).
@ashutoshcipher @aajisaka |
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.
Makes sense. FYI - This failure is observed with parallel mode enabled, hence was uncaught in YARN-11241(#4703)
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
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.
dropped a minor comment, link YARN-11241 in the Jira as the cause as well, no one is going to check git logs while backporting YARN-11241 or any such jira and he will potentially miss this
Thread.sleep(100); | ||
Thread.sleep(1000); |
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.
Is there some scope to change this hard-coded sleep with GenericTestUtils.waitFor
?
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.
Thank you very much for your help reviewing the code, I will use GenericTestUtils.waitFor
for code refactoring.
verifyLocalFileDeletion(logAggregationService); | ||
verifyLocalFileDeletion(logAggregationService, 4321L); |
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.
Is there some logic behind these numbers? If not I think we should generate random numbers instead, else someone adding a new tests, unaware of these numbers will landup into the same mess. But I am ok to do the present way if others feel this is better approach
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 for the suggestion, I also think it would be better to use random numbers.
@ayushtkn Please help to review the code again, thank you very much! |
🎊 +1 overall
This message was automatically generated. |
🎊 +1 overall
This message was automatically generated. |
@ayushtkn Please help to review the code again, thank you very much! |
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.
LGTM
@ashutoshcipher @ayushtkn Thank you very much for helping to review the code! |
…pload Failed After YARN-11241. (apache#4893). Contributed by fanshilun. Signed-off-by: Ayush Saxena <ayushsaxena@apache.org>
YARN-11305. Fix TestLogAggregationService#testLocalFileDeletionAfterUpload Failed After YARN-11241(#4703).
ERROR Message:
testReport:
https://ci-hadoop.apache.org/job/hadoop-multibranch/job/PR-4846/23/testReport/
Yarn's unit tests, with parallel mode enabled
Because the automatically generated application_id is the same, testLocalFileDeletionAfterUpload is affected by testLocalFileRemainsAfterUploadOnCleanupDisable
testLocalFileDeletionAfterUpload needs to check that the log of an application is deleted, and testLocalFileRemainsAfterUploadOnCleanupDisable regenerates the log of the same application.