Commit Graph

316 Commits

Author SHA1 Message Date
Chris Vest
b8e1341142
Future methods getNow() and cause() now throw on incomplete futures (#11594)
Motivation:
Since most futures in Netty are of the `Void` type, methods like `getNow()` and `cause()` cannot distinguish if the future has finished or not.
This can cause data race bugs which, in the case of `Void` futures, can be silent.

Modification:
The methods `getNow()` and `cause()` now throw an `IllegalStateException` if the future has not yet completed.
Most use of these methods are inside listeners, and so are not impacted.
One place in `AbstractBootstrap` was doing a racy read and has been adjusted.

Result:
Data race bugs around `getNow()` and `cause()` are no longer silent.
2021-08-24 15:47:27 +02:00
Chris Vest
7971a252a5
Clean up Future/Promises API (#11575)
Motivation:
The generics for the existing futures, promises, and listeners are too complicated.
This complication comes from the existence of `ChannelPromise` and `ChannelFuture`, which forces listeners to care about the particular _type_ of future being listened on.

Modification:
* Add a `FutureContextListener` which can take a context object as an additional argument. This allows our listeners to have the channel piped through to them, so they don't need to rely on the `ChannelFuture.channel()` method.
* Make the `FutureListener`, along with the `FutureContextListener` sibling, the default listener API, retiring the `GenericFutureListener` since we no longer need to abstract over the type of the future.
* Change all uses of `ChannelPromise` to `Promise<Void>`.
* Change all uses of `ChannelFuture` to `Future<Void>`.
* Change all uses of `GenericFutureListener` to either `FutureListener` or `FutureContextListener` as needed.
* Remove `ChannelFutureListener` and `GenericFutureListener`.
* Introduce a `ChannelFutureListeners` enum to house the constants that previously lived in `ChannelFutureListener`. These constants now implement `FutureContextListener` and take the `Channel` as a context.
* Remove `ChannelPromise` and `ChannelFuture` — all usages now rely on the plain `Future` and `Promise` APIs.
* Add static factory methods to `DefaultPromise` that allow us to create promises that are initialised as successful or failed.
* Remove `CompleteFuture`, `SucceededFuture`, `FailedFuture`, `CompleteChannelFuture`, `SucceededChannelFuture`, and `FailedChannelFuture`.
* Remove `ChannelPromiseNotifier`.

Result:
Cleaner generics and more straight forward code.
2021-08-20 09:55:16 +02:00
Aayush Atharva
25a0a6d425 Make variables final (#11548)
Motivation:
We should make variables `final` which are not reinstated again in code to match the code style and makes the code look better.

Modification:
Made couples of variables as `final`.

Result:
Variables marked as `final`.
2021-08-06 09:28:12 +02:00
Chris Vest
ef203fa6cb
Fix a number of javadoc issues (#11544)
Motivation:
Let's have fewer warnings about broken, missing, or abuse of javadoc comments.

Modification:
Added descriptions to throws clauses that were missing them.
Remove link clauses from throws clauses - these are implied.
Turned some javadoc comments into block comments because they were not applied to APIs.
Use code clauses instead of code tags.

Result:
Fewer javadoc crimes.
2021-08-06 09:14:04 +02:00
Aayush Atharva
b700793951 Remove Unused Imports (#11546)
Motivation:
There are lots of imports which are unused. We should get rid of them to make the code look better,

Modification:
Removed unused imports.

Result:
No unused imports.
2021-08-05 14:08:07 +02:00
Chris Vest
6b11f7fbc2
All *Bootstrap methods that used to return ChannelFuture now return Future<Channel> (#11517)
Bootstrap methods now return Future<Channel> instead of ChannelFuture

Motivation:
In #8516 it was proposed to at some point remove the specialised ChannelFuture and ChannelPromise.
Or at least make them not extend Future and Promise, respectively.
One pain point encountered in this discussion is the need to get access to the channel object after it has been initialised, but without waiting for the channel registration to propagate through the pipeline.

Modification:
Add a Bootstrap.createUnregistered method, which will return a Channel directly.
All other Bootstrap methods that previously returned ChannelFuture now return Future<Channel>

Result:
It's now possible to obtain an initialised but unregistered channel from a bootstrap, without blocking.
And the other bootstrap methods now only release their channels through the result of their futures, preventing racy access to the channels.
2021-08-03 19:43:38 +02:00
Chris Vest
fc922c98d8
Remove overrides of Throwable.fillInStackTrace (#11514)
Motivation:
Since Java 7, there are new constructors available that allow us to avoid initialising the stack traces of certain exceptions.

Modification:
Use these constructors instead of overriding Throwable.fillInStackTrace.

Result:
Cleaner code
2021-07-27 13:29:09 +02:00
Norman Maurer
1b1df557bf Make DnsNameResolver.cnameCache() public (#11520)
Motivation:

Users may want to clear the cache manually. For this it should be possible to access it first.

Modifications:

Change the visibility to public

Result:

Be able to clear the cache manually. Related to https://github.com/netty/netty/issues/11519
2021-07-27 12:05:44 +02:00
Nitesh Kant
ef7224480c Improve name matching in DNS answers (#11474)
__Motivation__

Upon receiving a DNS answer, we match whether the name in the question matches the name in the record. Some DNS servers we have encountered append a search domain to the record name which fails this match. eg: for question name `netty` and search domains `io` and `com`, we will do 2 queries: `netty.io.` and `netty.com.`, if the answer for `netty.io` contains `netty.com` then we ignore this record.

__Modification__

If the name in the record does not match the name in the question, append configured search domains to the question name to see if it matches the record name.

__Result__

Records names with appended search domains are still returned as valid answers.
2021-07-14 14:20:20 +02:00
Violeta Georgieva
e0940fed7a Skip the windows tests when there is an entry for localhost in the hosts file (#11385)
Motivation:

The tests must be executed only when there is no hosts file or
there is no entry for localhost in the hosts file. The tested functionality
is relevant only in these use cases.

Modifications:

Skip the windows tests when there is an entry for localhost in the hosts file.

Result:

Fix failing tests on Windows CI when using GitHub Actions
Related to #11384
2021-06-14 09:06:21 +02:00
Norman Maurer
abdaa769de
Remove Void*Promise (#11348)
Motivation:

Sometime in the past we introduced the concept of Void*Promise. As it turned out this was not a good idea at all as basically each handler in the pipeline need to be very careful to correctly handle this. We should better just remove this "optimization".

Modifications:

- Remove Void*Promise and all the related APIs
- Remove tests which were related to Void*Promise

Result:

Less error-prone API
2021-06-08 14:22:16 +02:00
Riley Park
cd4249218c
Migrate resolver-dns tests to JUnit 5 (#11326)
Motivation:

JUnit 5 is more expressive, extensible, and composable in many ways, and it's better able to run tests in parallel.

Modifications:

Use JUnit5 in tests

Result:

Related to https://github.com/netty/netty/issues/10757
2021-05-27 19:06:07 +02:00
Violeta Georgieva
7f04b28bc7 Add DefaultHostsFileEntriesResolver#addresses to provide all hosts file'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
2021-05-14 10:01:11 +02:00
Norman Maurer
91e41ae66e Cleanup test classes
Motivation:

We had some println left in the test-classes.

Modifications:

Remove println usage

Result:

Cleanup
2021-05-12 14:40:30 +02:00
Ben Evans
4fabd803c2
Only fall back to CNAME on A/AAAA queries (#11216)
Motivation:

DNS resolver falls back to trying CNAME if no records found, but should
only try this for A/AAAA queries. Does not make sense for other query
types, results in a redundant CNAME query that is just going to fail.

Modification:

Check query type before deciding to try CNAME. Only proceed if type is A
or AAAA.

Added unit test to verify CNAME is only tried after A/AAAA queries.

Result:

Fixes #11214.
2021-05-04 07:38:07 +02:00
Boris Unckel
0e8f5c5f7c Utilize i.n.u.internal.ObjectUtil to assert Preconditions (misc) (#11170) (#11186)
Motivation:

NullChecks resulting in a NullPointerException or IllegalArgumentException, numeric ranges (>0, >=0) checks, not empty strings/arrays checks must never be anonymous but with the parameter or variable name which is checked. They must be specific and should not be done with an "OR-Logic" (if a == null || b == null) throw new NullPointerEx.

Modifications:

* import static relevant checks
* Replace manual checks with ObjectUtil methods

Result:

All checks needed are done with ObjectUtil, some exception texts are improved in microbench and resolver-dns

Fixes #11170
2021-04-22 17:50:36 +02:00
Violeta Georgieva
311dae5168 Ensure DnsNameResolver resolves the host(computer) name on Windows (#11167)
Motivation:

On Windows DnsNameResolver is not able to resolve the host(computer) name as it is not in the hosts file and the DNS server is also not able to resolve it.
The exception below is the result of the resolution:
Caused by: java.net.UnknownHostException: failed to resolve 'host(computer)-name' after 2 queries
	at io.netty.resolver.dns.DnsResolveContext.finishResolve(DnsResolveContext.java:1013)
	at io.netty.resolver.dns.DnsResolveContext.tryToFinishResolve(DnsResolveContext.java:966)
	at io.netty.resolver.dns.DnsResolveContext.query(DnsResolveContext.java:414)
	at io.netty.resolver.dns.DnsResolveContext.tryToFinishResolve(DnsResolveContext.java:938)
	at io.netty.resolver.dns.DnsResolveContext.access$700(DnsResolveContext.java:63)
	at io.netty.resolver.dns.DnsResolveContext$2.operationComplete(DnsResolveContext.java:467)

Modifications:

On Windows DnsNameResolver maps host(computer) name to LOCALHOST

Result:

DnsNameResolver is able to resolve the host(computer) name on Windows

Fixes #11142
2021-04-20 08:25:41 +02:00
Norman Maurer
cf2d8460bc Fix compile error introduced by 06739ed890 2021-03-08 12:17:34 +01:00
Shoothzj
06739ed890 Allow to config dns bind address in DnsNameResolver (#11061)
Motivation:

The DnsResolver default start address listen to "0.0.0.0", which may be not what the user wants. 

Modification:

Add localAddress as a param of DnsNameResolver and its builder

Result:

The DnsNameResolver's bind address can be configured.
2021-03-08 12:09:09 +01:00
Idel Pivnitskiy
a1172bf9c6 Less noisy logging in DnsServerAddressStreamProviders (#11031)
Motivation:

It is not uncommon to run Netty on OS X without the specific
`MacOSDnsServerAddressStreamProvider`. The current log message is too
verbose because it prints a full stack trace on the console while a
simple logging message would have been enough.

Modifications:

- Print a `WARN` message when `MacOSDnsServerAddressStreamProvider`
class is not found;
- Print a `ERROR` message with a stack trace when the class was found
but could not be loaded due to some other reasons;

Result:

Less noise in logs.
2021-02-23 11:17:47 +01:00
Violeta Georgieva
b1ce20c080 Allow blocking calls when parsing etcResolver/hosts files (#11009)
Motivation:

When etcResolver/hosts files are parsed, FileInputStream.read(...) is internally called by

- UnixResolverDnsServerAddressStreamProvider#parseEtcResolverSearchDomains
- UnixResolverDnsServerAddressStreamProvider#parseEtcResolverOptions
- HostsFileParser#parse

This will cause the error below when BlockHound is enabled

reactor.blockhound.BlockingOperationError: Blocking call! java.io.FileInputStream#readBytes
     	at java.io.FileInputStream.readBytes(FileInputStream.java)
     	at java.io.FileInputStream.read(FileInputStream.java:255)

Modifications:

- Add whitelist entries to BlockHound configuration
- Fix typos in UnixResolverDnsServerAddressStreamProvider
- Add tests

Result:

Fixes #11004
2021-02-11 11:05:14 +01:00
Idel Pivnitskiy
643b8471e2 Improve logging in DnsServerAddressStreamProviders (#10848)
Motivation:

`DnsServerAddressStreamProviders` tries to load `MacOSDnsServerAddressStreamProvider`
on macOS. However, it doesn't warn users when `MacOSDnsServerAddressStreamProvider`
is not awailable, which may cause incorrect results for DNS resolutions.

Modifications:

- Log at warn level if `MacOSDnsServerAddressStreamProvider` is not found on macOS;
- Log at debug level when `MacOSDnsServerAddressStreamProvider` is loaded and available;

Result:

macOS users are notified when `MacOSDnsServerAddressStreamProvider` is not available.
2020-12-10 15:22:19 +01:00
Norman Maurer
23c0bbb904 Don't use the cname cache when using DnsRecordResolveContext (#10808)
Motivation:

The DnsNameResolver internally follows CNAME indirects for all records types, and supports caching for CNAME resolution and A* records. For DNS record types that are not cached (e.g. SRV records) the caching of CNAME records may result in failures at incorrect times. For example if a CNAME record has a larger TTL than the entries it resolves this may result in failures which don't occur if the CNAME cache is disabled.

Modifications:

- Don't cache CNAME and also dont use the cache for CNAME when using DnsRecordResolveContext
- Add unit test

Result:

More correct resolving and also not possible to have failures due CNAME still be in the cache while the queried record experied
2020-11-26 15:35:24 +01:00
Norman Maurer
eeece4cfa5 Use http in xmlns URIs to make maven release plugin happy again (#10788)
Motivation:

https in xmlns URIs does not work and will let the maven release plugin fail:

```
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  1.779 s
[INFO] Finished at: 2020-11-10T07:45:21Z
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.5.3:prepare (default-cli) on project netty-parent: Execution default-cli of goal org.apache.maven.plugins:maven-release-plugin:2.5.3:prepare failed: The namespace xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" could not be added as a namespace to "project": The namespace prefix "xsi" collides with an additional namespace declared by the element -> [Help 1]
[ERROR]
```

See also https://issues.apache.org/jira/browse/HBASE-24014.

Modifications:

Use http for xmlns

Result:

Be able to use maven release plugin
2020-11-10 10:51:05 +01:00
Roman Puchkovskiy
dba46aa3da Fix native image build on modern GraalVM versions for the cases when the program uses netty-dns (#10630)
Motivation:

Since GraalVM version 19.3.0, instances of java.net.InetAddress (and its subclasses Inet4Address and Inet6Address) are not allowed in native image heap (that is, they cannot be stored in static fields of classes initialized at build time or be reachable through static fields of such classes). When building a native image, it makes sense to initialize at build time as many classes as possible.
But some fields of some classes in Netty (for example, NetUtil.LOCALHOST4) contain InetAddress instances. If a program is using code path that makes it possible to reach such fields at build time initialization, it becomes impossible to build a native image initializing core Netty classes initialized at runtime. An example of such a program is a client that uses netty-dns.

Modifications:

- Add netty-testsuite-native-image-client Maven module to test that such an example program can be built after the corresponding fixes
- Add native-image.properties to resolver-dns module to move initialization of some classes to runtime (some of them are parsing configuration during initialization, so it makes no sense to initialize them at build time; for others, it's needed to avoid InetAddress reachability at build time)
- Add substitutions for NetUtil.LOCALHOST4, NetUtil.LOCALHOST6 and NetUtil.LOCALHOST to overcome the InetAddress-related prohibition
- Extract some initialization code from NetUtil to NetUtilInitializations to allow it to be used by the substitutions

Result:

A client program using netty-dns with --initialize-at-build-time=io.netty builds successfully
2020-10-26 08:49:31 +01:00
Artem Smotrakov
b8ae2a2af4 Enable nohttp check during the build (#10708)
Motivation:

HTTP is a plaintext protocol which means that someone may be able
to eavesdrop the data. To prevent this, HTTPS should be used whenever
possible. However, maintaining using https:// in all URLs may be
difficult. The nohttp tool can help here. The tool scans all the files
in a repository and reports where http:// is used.

Modifications:

- Added nohttp (via checkstyle) into the build process.
- Suppressed findings for the websites
  that don't support HTTPS or that are not reachable

Result:

- Prevent using HTTP in the future.
- Encourage users to use HTTPS when they follow the links they found in
  the code.
2020-10-23 15:26:25 +02:00
Norman Maurer
3f2c5ccd46 Replace deprecated Assert.assertThat(...) with MatcherAssert.assertThat(...) (#10699)
Motivation:

junit deprecated Assert.assertThat(...)

Modifications:

Use MatcherAssert.assertThat(...) as replacement for deprecated method

Result:

Less deprecation warnings
2020-10-18 14:55:21 +02:00
Artem Smotrakov
f0448d6a8a Fix or suppress LGTM findings (#10689)
Motivation:

LGTM reports multiple issues. They need to be triaged,
and real ones should be fixed.

Modifications:
- Fixed multiple issues reported by LGTM, such as redundant conditions,
  resource leaks, typos, possible integer overflows.
- Suppressed false-positives.
- Added a few testcases.

Result:

Fixed several possible issues, get rid of false alarms in the LGTM report.
2020-10-17 09:57:52 +02:00
Norman Maurer
5b00058fa7 Ensure we don't leak the ClassLoader in the backtrace (#10691)
Motivation:

We have a few classes in which we store and reuse static instances of various exceptions. When doing so it is important to also override fillInStacktrace() and so prevent the leak of the ClassLoader in the internal backtrace field.

Modifications:

- Add overrides of fillInStracktrace when needed
- Move ThrowableUtil usage in the static methods

Result:

Fixes https://github.com/netty/netty/pull/10686
2020-10-15 20:50:01 +02:00
Norman Maurer
d6a723ab9d Use all configured nameservers when using DnsNameResolver in all cases (#10503)
Motivation:

Due a change introduced in 68105b257d we incorrectly skipped the usage of nameservers in some cases.

Modifications:

Only fetch a new stream of nameserver if the hostname not matches the original hostname in the query.

Result:

Use all configured nameservers. Fixes https://github.com/netty/netty/issues/10499
2020-08-31 09:12:40 +02:00
Chris Vest
6150a0e3c5
Expose a LoggingDnsQueryLifeCycleObserverFactory (#10488)
Expose a LoggingDnsQueryLifeCycleObserverFactory

Motivation:
 There is a use case for having logging in the DnsNameResolver, similar to the LoggingHandler.
 Previously, one could set `traceEnabled` on the DnsNameResolverBuilder, but this is not very configurable.
 Specifically, the log level and the logger context cannot be changed.

Modification:
 Expose a LoggingDnsQueryLifeCycleObserverFactory, that permit changing the log-level
 and logger context.

Result:
 It is now possible to get logging in the DnsNameResolver at a custom log level and logger,
 without very much effort.

Fixes #10485
2020-08-19 17:38:29 +02:00
Norman Maurer
68dbc7703a Correctly limit queries done to resolve unresolved nameservers (#10478)
Motivation:

We need limit the number of queries done to resolve unresolved nameserver as otherwise we may never fail the resolve when there is a missconfigured dns server that lead to a "resolve loop".

Modifications:

- When resolve unresolved nameservers ensure we use the allowedQueries as max upper limit for queries so it will eventually fail
- Add unit tests

Result:

No more possibility to fail in a loop while resolve. This is related to https://github.com/netty/netty/issues/10420
2020-08-14 16:09:40 +02:00
Norman Maurer
cc33da49aa DnsAddressResolverGroup should respect configured EventLoop (#10479)
Motivation:

DnsAddressResolverGroup allows to be constructed with a DnsNameResolverBuilder and so should respect its configured EventLoop.

Modifications:

- Correctly respect the configured EventLoop
- Ensure there are no thread-issues by calling copy()
- Add unit tests

Result:

Fixes https://github.com/netty/netty/issues/10460
2020-08-13 20:32:24 +02:00
Koji Lin
1be1523a9e Fix DnsNameResolver may have LEAK ByteBuf after cancelling the returned future (#10448)
Motivation:

If we cancel the returned future of resolve query, we may get LEAK. Try to release the ByteBuf if netty can't pass the DnsRawRecord to the caller.

Modification:

Using debug mode I saw there are two places that don't handle trySuccess with release. Try to release there.

Result:

Fixes #10447.
2020-08-03 07:58:20 +02:00
Norman Maurer
040419be8a Fix possible StackOverflowError when try to resolve authorative names… (#10337)
Motivation:

There is a possibility to end up with a StackOverflowError when trying to resolve authorative nameservers because of incorrect wrapping the AuthoritativeDnsServerCache.

Modifications:

Ensure we don't end up with an overflow due wrapping

Result:

Fixes https://github.com/netty/netty/issues/10246
2020-06-04 19:14:29 +02:00
Norman Maurer
3f7dbd8790 We should fail fast when a CNAME loop is detected (#10305)
Motivation:

Once a CNAME loop was detected we can just fail fast and so reduce the number of queries.

Modifications:

Fail fast once a CNAME loop is detected

Result:

Fail fast
2020-05-20 07:10:47 +02:00
Norman Maurer
bdb5e20d99 Use allocation free algorithm to detect CNAME cache loops (#10291)
Motivation:

We did use a HashSet to detect CNAME cache loops which needs allocations. We can use an algorithm that doesnt need any allocations

Modifications:

Use algorithm that doesnt need allocations

Result:

Less allocations on the slow path
2020-05-18 14:30:24 +02:00
Norman Maurer
b40ae95044 Select correct nameserver for CNAME (#10272)
Motivation:

The nameserver that should / must be used to resolve a CNAME may be different then the nameserver that was selected for the hostname to resolve. Failing to select the correct nameserver may result in problems during resolution.

Modifications:

Use the correct DnsServerAddressStream for CNAMEs

Result:

Always use the correct DnsServerAddressStream for CNAMEs and so fix resolution failures which could accour when CNAMEs are in the mix that use a different domain then the original hostname that we try to resolve
2020-05-12 08:47:11 +02:00
Norman Maurer
7b56aabec6 Don't log with warn level in the DnsNameResolver in most cases (#10225)
Motivation:

We should only log with warn level if something really critical happens as otherwise we may spam logs and confuse the user.

Modifications:

- Change log level to debug for most cases

Result:

Less noisy logging
2020-04-29 08:08:39 +02:00
Norman Maurer
fe20550a22 Detect CNAME loops in the CNAME cache while trying to resolve (#10221)
Motivation:

We need to detect CNAME loops during lookup the DnsCnameCache as otherwise we may try to follow cnames forever.

Modifications:

- Correctly detect CNAME loops in the cache
- Add unit test

Result:

Fixes https://github.com/netty/netty/issues/10220
2020-04-28 11:06:46 +02:00
Fabien Renaud
0c7a01503a Dns resolver: honor resolv.conf timeout, rotate and attempts options (#10207)
Motivations
-----------
DnsNameResolverBuilder and DnsNameResolver do not auto-configure
themselves uing default options define in /etc/resolv.conf.
In particular, rotate, timeout and attempts options are ignored.

Modifications
-------------
 - Modified UnixResolverDnsServerAddressStreamProvider to parse ndots,
attempts and timeout options all at once and use these defaults to
configure DnsNameResolver when values are not provided by the
DnsNameResolverBuilder.
 - When rotate option is specified, the DnsServerAddresses returned by
UnixResolverDnsServerAddressStreamProvider is rotational.
 - Amend resolv.conf options with the RES_OPTIONS environment variable
when present.

Result:

Fixes https://github.com/netty/netty/issues/10202
2020-04-28 09:33:11 +02:00
minux
35e95e9a6e Stop sending DNS queries if promise is cancelled (#10171)
Motivation:
A user might want to cancel DNS resolution when it takes too long.
Currently, there's no way to cancel the internal DNS queries especially when there's a lot of search domains.

Modification:
- Stop sending a DNS query if the original `Promise`, which was passed calling `resolve()`, is canceled.

Result:
- You can now stop sending DNS queries by cancelling the `Promise`.
2020-04-07 13:52:08 +02:00
minux
3a2bf416bd Fix a bug where making IPv6 DnsQuestion when it's not supported (#10170)
Motivation:
Related https://github.com/line/armeria/issues/2463
Here is an example that an NIC has only link local address for IPv6.
```
$ ipaddr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
3: eth0@if18692: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1460 qdisc noqueue
    link/ether 1a:5e:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 10.xxx.xxx.xxx/24 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link
       valid_lft forever preferred_lft forever
```
If the NICs have only local or link local addresses, We should not send IPv6 DNS queris.

Modification:
- Ignore link-local IPv6 addresses which may exist even on a machine without IPv6 network.

Result:
- `DnsNameResolver` does not send DNS queries for AAAA when IPv6 is not available.
2020-04-07 12:08:50 +02:00
Norman Maurer
fd0d06ee39
Replace reflection usage with MethodHandles when performance matters (#10097)
Motivation:

As we have java8 as a minimum target we can use MethodHandles. We should do so when we expect to have a method called multiple times.

Modifications:

- Replace usage of reflection with MethodHandles where it makes sense
- Remove some code which was there to support java < 8

Result:

Faster code
2020-03-11 21:04:40 +01:00
Norman Maurer
dddde43dcf Use MacOSDnsServerAddressStreamProvider when on the classpath and we … (#10079)
Motivation:

939e928312 introduced MacOSDnsServerAddressStreamProvider which will ensure the right nameservers are selected when running on MacOS. To ensure this is done automatically on MacOS we should use it by default on these platforms.

Modifications:

Try to use MacOSDnsServerAddressStreamProvider when on MacOS via reflection and fallback if not possible

Result:

Ensure the right nameservers are used on MacOS even when a VPN (for example) is used.
2020-03-06 11:42:19 +01:00
Norman Maurer
118e1c66dc Add log level check simply before logging. (#10080)
Motivation:

In general, we will close the debug log in a product environment. However, logging without external level check may still affect performance as varargs will need to allocate an array.

Modification:

Add log level check simply before logging.

Result:

Improve performance slightly in a product environment.
2020-03-05 14:46:22 +01:00
Norman Maurer
6a43807843
Use lambdas whenever possible (#9979)
Motivation:

We should update our code to use lamdas whenever possible

Modifications:

Use lambdas when possible

Result:

Cleanup code for Java8
2020-01-30 09:28:24 +01:00
Norman Maurer
9e29c39daa
Cleanup usage of Channel*Handler (#9959)
Motivation:

In next major version of netty users should use ChannelHandler everywhere. We should ensure we do the same

Modifications:

Replace usage of deprecated classes / interfaces with ChannelHandler

Result:

Use non-deprecated code
2020-01-20 17:47:17 -08:00
Norman Maurer
776e38af88 Remove @UnstableApi annotation from resolver-* (#9952)
Motivation:

The resolver API and implementations should be considered stable by now so we should not mark these with @UnstableApi

Modifications:

Remove @UnstableApi annotation from API and implementation of resolver

Result:

Make it explicit that the API is considered stable
2020-01-15 09:18:02 +01:00
Norman Maurer
7931501769 Ignore inline comments when parsing nameservers (#9894)
Motivation:

The resolv.conf file may contain inline comments which should be ignored

Modifications:

- Detect if we have a comment after the ipaddress and if so skip it
- Add unit test

Result:

Fixes https://github.com/netty/netty/issues/9889
2019-12-18 21:14:17 +01:00