-
Notifications
You must be signed in to change notification settings - Fork 9.2k
HADOOP-19272. S3A: AWS SDK 2.25.53 warnings logged by transfer manager #7048
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
HADOOP-19272. S3A: AWS SDK 2.25.53 warnings logged by transfer manager #7048
Conversation
48e3762 to
1306ef4
Compare
|
🎊 +1 overall
This message was automatically generated. |
Disables all logging below error in the AWS SDK Transfer Manager. This is done in ClientManagerImpl construction so is automatically done during S3A FS initialization. ITests verify that * It is possible to restore the warning log. This verifies the validity of the test suite, and will identify when an SDK update fixes this regression. * Constructing an S3A FS instance will disable the logging. The log manipulation code is lifted from Cloudstore, where it was used to dynamically enable logging. It uses reflection to load the Log4J binding; all uses of the API catch and swallow exceptions. This is needed to avoid failures when running against different log backends This is an emergency fix -we could come up with a better design for the reflection based code using the new DynMethods classes. But this is based on working code, which is always good. Change-Id: I51b9fc40bd3c7d7df55258889811df6a9cb0ba9a
ae12e8c to
da44d53
Compare
|
🎊 +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.
+1, LGTM.
What is the plan for this long term though? At some point we will upgrade the SDK, where this message has been downgraded to a debug. And then testNoisyLogging will start failing. So then do we revert or fix the test?
EDIT: I think we want to disable transfer manager logs permanently, so it'll just be fixing the test.
mukund-thakur
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.
+1 overall looks good tome as well.
And yes we need a plan after AWS upgrade.
the test failure will be how we verify that all is good. at which point we can modify the test to fail if any warnings come from the manager.
I'm going to propose moving off it entirely
also I no longer trust the code. |
#7048) Disables all logging below error in the AWS SDK Transfer Manager. This is done in ClientManagerImpl construction so is automatically done during S3A FS initialization. ITests verify that * It is possible to restore the warning log. This verifies the validity of the test suite, and will identify when an SDK update fixes this regression. * Constructing an S3A FS instance will disable the logging. The log manipulation code is lifted from Cloudstore, where it was used to dynamically enable logging. It uses reflection to load the Log4J binding; all uses of the API catch and swallow exceptions. This is needed to avoid failures when running against different log backends This is an emergency fix -we could come up with a better design for the reflection based code using the new DynMethods classes. But this is based on working code, which is always good. Contributed by Steve Loughran
Disables all logging by the AWS SDK Transfer Manager.
This is done in ClientManagerImpl construction so is automatically done during S3AFS initialization.
ITests verify that
The log manipulation code is lifted from Cloudstore, where it was used to dynamically enable logging. It uses reflection to load the Log4J binding; all uses of the API catch and swallow exceptions.
This is needed to avoid failures when running against different log backends
This is an emergency fix -we could come up with a better design for the reflection based code using the new DynMethods classes. But this is based on working code, which is always good.
How was this patch tested?
For code changes:
LICENSE,LICENSE-binary,NOTICE-binaryfiles?