Skip to content

Add DefaultHostsFileEntriesResolver#addresses to provide all hosts file's entries for a hostname#11246

Merged
normanmaurer merged 5 commits intonetty:4.1from
violetagg:hosts-file-entries
May 14, 2021
Merged

Add DefaultHostsFileEntriesResolver#addresses to provide all hosts file's entries for a hostname#11246
normanmaurer merged 5 commits intonetty:4.1from
violetagg:hosts-file-entries

Conversation

@violetagg
Copy link
Copy Markdown
Member

Motivation:

DefaultHostsFileEntriesResolver should provide all hosts file's entries for a hostname when
DnsNameResolver#resolveAll as opposed to the current implementation where only the first
entry is taken into consideration.

Modification:

  • Add DefaultHostsFileEntriesResolver#addresses to provide all hosts file's entries for a hostname
  • Add HostsFileEntriesProvider to provide all hosts file's entries for a hostname and to keep
    backwards compatibility for HostsFileEntries and HostsFileParser
  • DnsNameResolver#resolveAll uses the new DefaultHostsFileEntriesResolver#addresses
  • BlockHound configuration: replace HostsFileParser#parse with HostsFileEntriesProvider$ParserImpl#parse
    as the latter does the parsing
  • Add junit tests

Result:
Fixes #10834

…le's entries for a hostname

Motivation:
DefaultHostsFileEntriesResolver should provide all hosts file's entries for a hostname when
DnsNameResolver#resolveAll as opposed to the current implementation where only the first
entry is taken into consideration

Modification:
- Add DefaultHostsFileEntriesResolver#addresses to provide all hosts file's entries for a hostname
- Add HostsFileEntriesProvider to provide all hosts file's entries for a hostname and to keep
backwards compatibility for HostsFileEntries and HostsFileParser
- DnsNameResolver#resolveAll uses the new DefaultHostsFileEntriesResolver#addresses
- BlockHound configuration: replace HostsFileParser#parse with HostsFileEntriesProvider$ParserImpl#parse
as the latter does the parsing
- Add junit tests

Result:
Fixes #10834
@violetagg
Copy link
Copy Markdown
Member Author

@normanmaurer How can I find the test that is not passing the build on CI?

@normanmaurer
Copy link
Copy Markdown
Member

@violetagg it failed due some network problems:

2021-05-11T18:51:11.3115666Z [INFO] ------------------------------------------------------------------------
2021-05-11T18:51:11.3116421Z [INFO] BUILD FAILURE
2021-05-11T18:51:11.3117366Z [INFO] ------------------------------------------------------------------------
2021-05-11T18:51:11.3118128Z [INFO] Total time:  20:49 min
2021-05-11T18:51:11.3118926Z [INFO] Finished at: 2021-05-11T18:51:11Z
2021-05-11T18:51:11.3119884Z [INFO] ------------------------------------------------------------------------
2021-05-11T18:51:11.3125549Z [ERROR] Failed to execute goal on project netty-codec-dns: Could not resolve dependencies for project io.netty:netty-codec-dns:jar:4.1.64.Final-SNAPSHOT: The following artifacts could not be resolved: org.apache.directory.server:apacheds-core:jar:1.5.7, org.apache.directory.server:apacheds-core-api:jar:1.5.7: Could not transfer artifact org.apache.directory.server:apacheds-core:jar:1.5.7 from/to central (https://repo.maven.apache.org/maven2): transfer failed for https://repo.maven.apache.org/maven2/org/apache/directory/server/apacheds-core/1.5.7/apacheds-core-1.5.7.jar: Connection timed out (Read failed) -> [Help 1]
2021-05-11T18:51:11.3129407Z [ERROR] 
2021-05-11T18:51:11.3130408Z [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
2021-05-11T18:51:11.3131587Z [ERROR] Re-run Maven using the -X switch to enable full debug logging.
2021-05-11T18:51:11.3132323Z [ERROR] 
2021-05-11T18:51:11.3133240Z [ERROR] For more information about the errors and possible solutions, please read the following articles:
2021-05-11T18:51:11.3134751Z [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
2021-05-11T18:51:11.3135857Z [ERROR] 
2021-05-11T18:51:11.3136650Z [ERROR] After correcting the problems, you can resume the build with the command
2021-05-11T18:51:11.3137718Z [ERROR]   mvn <args> -rf :netty-codec-dns
2021-05-11T18:51:11.4706176Z 1

Copy link
Copy Markdown
Member

@normanmaurer normanmaurer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

one nit... then I think we are ready to go

@normanmaurer normanmaurer requested a review from NiteshKant May 12, 2021 16:09
@normanmaurer
Copy link
Copy Markdown
Member

/cc @NiteshKant can you check as well ?

Copy link
Copy Markdown
Member

@normanmaurer normanmaurer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is fine but one question left @violetagg that I am not sure about...

@normanmaurer normanmaurer added this to the 4.1.64.Final milestone May 12, 2021
@normanmaurer normanmaurer merged commit fa8f7a3 into netty:4.1 May 14, 2021
@violetagg
Copy link
Copy Markdown
Member Author

@normanmaurer @NiteshKant Thanks a lot!

normanmaurer pushed a commit that referenced this pull request May 14, 2021
…le's entries for a hostname (#11246)

Motivation:
DefaultHostsFileEntriesResolver should provide all hosts file's entries for a hostname when
DnsNameResolver#resolveAll as opposed to the current implementation where only the first
entry is taken into consideration

Modification:
- Add DefaultHostsFileEntriesResolver#addresses to provide all hosts file's entries for a hostname
- Add HostsFileEntriesProvider to provide all hosts file's entries for a hostname and to keep
backwards compatibility for HostsFileEntries and HostsFileParser
- DnsNameResolver#resolveAll uses the new DefaultHostsFileEntriesResolver#addresses
- BlockHound configuration: replace HostsFileParser#parse with HostsFileEntriesProvider$ParserImpl#parse
as the latter does the parsing
- Add junit tests

Result:
Fixes #10834
@normanmaurer
Copy link
Copy Markdown
Member

@violetagg I need to investigate... with this change I see a test-failure in servicetalk... It seems to return the IPV6 address for localhost when we expect the IPV4. I need to investigate if the problem is with the test or the change here that it may return the IPV6 as first when we want the IPV4.

@violetagg
Copy link
Copy Markdown
Member Author

@violetagg I need to investigate... with this change I see a test-failure in servicetalk... It seems to return the IPV6 address for localhost when we expect the IPV4. I need to investigate if the problem is with the test or the change here that it may return the IPV6 as first when we want the IPV4.

if I can help just tell me ...

@normanmaurer
Copy link
Copy Markdown
Member

@violetagg all good... I debugged a bit with the team and we are ok from a netty side..

@violetagg
Copy link
Copy Markdown
Member Author

@violetagg all good... I debugged a bit with the team and we are ok from a netty side..

That's good. Thanks

@violetagg violetagg deleted the hosts-file-entries branch May 14, 2021 12:55
raidyue pushed a commit to raidyue/netty that referenced this pull request Jul 8, 2022
…le's entries for a hostname (netty#11246)


Motivation:
DefaultHostsFileEntriesResolver should provide all hosts file's entries for a hostname when
DnsNameResolver#resolveAll as opposed to the current implementation where only the first
entry is taken into consideration

Modification:
- Add DefaultHostsFileEntriesResolver#addresses to provide all hosts file's entries for a hostname
- Add HostsFileEntriesProvider to provide all hosts file's entries for a hostname and to keep
backwards compatibility for HostsFileEntries and HostsFileParser
- DnsNameResolver#resolveAll uses the new DefaultHostsFileEntriesResolver#addresses
- BlockHound configuration: replace HostsFileParser#parse with HostsFileEntriesProvider$ParserImpl#parse
as the latter does the parsing
- Add junit tests

Result:
Fixes netty#10834

* Address feedback
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

AnnotatedConnectException: Connection refused: localhost/127.0.1.1:37655

3 participants