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
HDFS-16753. WebHDFSHandler should reject non-compliant requests #4834
base: trunk
Are you sure you want to change the base?
Conversation
💔 -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.
Requiring non-null noid makes sense to me.
This looks hard to test for. Is there any coverage currently that you can cite?
The original test is
|
So now the test passes TestWebHdfsFileSystemContract#testResponseCode when 'null' doesn't resolve -- as expected -- but also passes when 'null' resolves? (What does resolve of 'null' even look like?). |
No. The update doesn't allow a null value (as opposed to a host name "null") to be misinterpreted as a string. You could still have a host named "null", but that doesn't apply in the case of a missing parameter. |
cb6d793
to
9afc036
Compare
💔 -1 overall
This message was automatically generated. |
9afc036
to
75b7e31
Compare
💔 -1 overall
This message was automatically generated. |
Make a non-null nnId a precondition for creating a DFSClient.
75b7e31
to
38af11a
Compare
💔 -1 overall
This message was automatically generated. |
Description of PR
When the nnId is not provided to the WebHDFSClient, the request uses null to generate a URI using a host name of "null" to construct a DFSClient instance. In environments where the host name "null" doesn't resolve, the test passes due to the unresolvable name. If the host name "null" does resolve, then this results in repeated attempts through the retry mechanism, eventually causing a timeout and a failed test result.
This change make the parameter a precondition for constructing the DFSClient, which throws an exception, rejecting the request, and return the expected 400 status code.
Make a non-null nnId a precondition for creating a DFSClient.
How was this patch tested?
The patch was tested using both Maven Surefire and an IDE to demonstrate that the expected 400 status code was returned when the parameter was missing.
For code changes:
LICENSE
,LICENSE-binary
,NOTICE-binary
files?