Netty

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
DnsNameResolver search domains support

Motivation:

The current DnsNameResolver does not support search domains resolution. Search domains resolution is supported out of the box by the java.net resolver, making the DnsNameResolver not able to be a drop in replacement for io.netty.resolver.DefaultNameResolver.

Modifications:

The DnsNameResolverContext resolution has been modified to resolve a list of search path first when it is configured so. The resolve method now uses the following algorithm:

if (hostname is absolute (start with dot) || no search domains) {

searchAsIs

} else {

if (numDots(name) >= ndots) {

searchAsIs

}

if (searchAsIs wasn't performed or failed) {

searchWithSearchDomainsSequenciallyUntilOneSucceeds

}

}

The DnsNameResolverBuilder provides configuration for the search domains and the ndots value. The default search domains value is configured with the OS search domains using the same native configuration the java.net resolver uses.

Result:

The DnsNameResolver performs search domains resolution when they are present.

Remove unneeded calls to hasScheduledTasks() when fetching from scheduled task queue for event executors.

Motivation:

Currently in the single threaded and global event executors when the scheduled task queue is drained, there is a call to hasScheduledTasks(). If there are scheduled tasks then the the code polls the queue for tasks. The poll method duplicates the exact logic of hasScheduledTasks(). This involves two calls to nanoTime when one seems sufficient.

Modifications:

Directly poll the queue for tasks and break if the task returned is null.

Result:

Should be no noticeable impact on functionality. Two calls to nanoTime have been coarsened into a single call.

Remove unneeded calls to hasScheduledTasks() when fetching from scheduled task queue for event executors.

Motivation:

Currently in the single threaded and global event executors when the scheduled task queue is drained, there is a call to hasScheduledTasks(). If there are scheduled tasks then the the code polls the queue for tasks. The poll method duplicates the exact logic of hasScheduledTasks(). This involves two calls to nanoTime when one seems sufficient.

Modifications:

Directly poll the queue for tasks and break if the task returned is null.

Result:

Should be no noticeable impact on functionality. Two calls to nanoTime have been coarsened into a single call.

Fix NPE in OpenSslEngine

Motivation:

The gRPC interop tests fail due to a NPE in OpenSslEngine.

Caused by: java.lang.NullPointerException

at io.netty.handler.ssl.OpenSslEngine.setSSLParameters(OpenSslEngine.java:1473)

Modifications:

Add a null check

Result:

No more NPE exceptions :-)

Fix NPE in OpenSslEngine

Motivation:

The gRPC interop tests fail due to a NPE in OpenSslEngine.

Caused by: java.lang.NullPointerException

at io.netty.handler.ssl.OpenSslEngine.setSSLParameters(OpenSslEngine.java:1473)

Modifications:

Add a null check

Result:

No more NPE exceptions :-)

Removed HeapByteBuffer address field check.

Motivation:

In JDK9 heap byte buffers have an address field, so we have to remove

the current check as it is invalid in JDK9.

Modifications:

Removed the address field check for heap byte buffers.

Result:

Netty continues to find sun.misc.Unsafe in JDK9 as in previous JDKs.

Removed HeapByteBuffer address field check.

Motivation:

In JDK9 heap byte buffers have an address field, so we have to remove

the current check as it is invalid in JDK9.

Modifications:

Removed the address field check for heap byte buffers.

Result:

Netty continues to find sun.misc.Unsafe in JDK9 as in previous JDKs.

Use reflection to call cleaner on direct byte buffers in JDK9.

Motivation:

Project Jigsaw in JDK9 has moved the direct byte buffer cleaner from

sun.misc.Cleaner to java.lang.ref.Cleaner$Cleanable. This cause the

current platform tests to throw a ClassNotFoundException, disabling the

use of direct byte buffer cleaners.

Modifications:

I use reflection to find the clean method in either sun.misc.Cleaner or

java.lang.ref.Cleaner$Cleanable.

Result:

Netty uses direct byte buffers on JDK9 as it already do on earlier JDKs.

Use reflection to call cleaner on direct byte buffers in JDK9.

Motivation:

Project Jigsaw in JDK9 has moved the direct byte buffer cleaner from

sun.misc.Cleaner to java.lang.ref.Cleaner$Cleanable. This cause the

current platform tests to throw a ClassNotFoundException, disabling the

use of direct byte buffer cleaners.

Modifications:

I use reflection to find the clean method in either sun.misc.Cleaner or

java.lang.ref.Cleaner$Cleanable.

Result:

Netty uses direct byte buffers on JDK9 as it already do on earlier JDKs.

Add version check for JDK9 and beyond.

Motivation:

Netty's platform dependent parts should know about JDK9.

Modifications:

JDK9 introduce Runtime$Version Runtime.version() which has an int major()

method that always return the major Java version. I call that method to

get the Java major version.

Result:

Netty will recognize all future JDK versions.

Add version check for JDK9 and beyond.

Motivation:

Netty's platform dependent parts should know about JDK9.

Modifications:

JDK9 introduce Runtime$Version Runtime.version() which has an int major()

method that always return the major Java version. I call that method to

get the Java major version.

Result:

Netty will recognize all future JDK versions.

[maven-release-plugin] prepare for next development iteration

[maven-release-plugin] prepare release netty-3.10.6.Final

Add MessageToBufferedByteEncoder for better performance

Motivation:

MessageToMessageEncoder always allocate a new buffer per encode call and pass it through the pipeline via a write call. This can have negative performance impact if the users does a lot of write calls before doing a flush as this may produce a lot of small buffers that needs to get allocated and also written to the underlying transport. For this situations it can be a lot better to just allocate one buffer, encoder everything into this buffer and only write it the the transport once a flush happens.

Modifications:

Add a new MessageToBufferedByteEncoder which should be used if more writes then flush operations are expected.

Result:

Better performance.

Use ResourceLeakDetectorFactory in HashedWheelTimer

Motivation:

We recently added the ResourceLeakDetectorFactory but missed to updated HashedWheelTimer to use it.

Modifications:

- Add new abstract method to ResourceLeakDetectorFactory that allows to provide also samplingInterval and maxActive args.

- Deprecate most constructors in ResourceLeakDetector and add doc explaining that people should use ResourceLeakDetectorFactory

Result:

Custom ResourceLeakDetectorFactory will also be used in HashedWheelTimer if configured.

Use ResourceLeakDetectorFactory in HashedWheelTimer

Motivation:

We recently added the ResourceLeakDetectorFactory but missed to updated HashedWheelTimer to use it.

Modifications:

- Add new abstract method to ResourceLeakDetectorFactory that allows to provide also samplingInterval and maxActive args.

- Deprecate most constructors in ResourceLeakDetector and add doc explaining that people should use ResourceLeakDetectorFactory

Result:

Custom ResourceLeakDetectorFactory will also be used in HashedWheelTimer if configured.

Allow to disable ResourceLeak creation when worker thread is deamon in HashedWheelTimer

Motivation:

Sometimes a shared HashedWheelTimer can not easily be stopped in a good place. If the worker thread is daemon this is not a big deal and we should allow to not log a leak.

Modifications:

Add another constructor which allows to disable resource leak detection if worker thread is used.

Result:

Not log resource leak when HashedWheelTimer is not stopped and the worker thread is a deamon thread.

Allow to disable ResourceLeak creation when worker thread is deamon in HashedWheelTimer

Motivation:

Sometimes a shared HashedWheelTimer can not easily be stopped in a good place. If the worker thread is daemon this is not a big deal and we should allow to not log a leak.

Modifications:

Add another constructor which allows to disable resource leak detection if worker thread is used.

Result:

Not log resource leak when HashedWheelTimer is not stopped and the worker thread is a deamon thread.

Change minimum JDK version for compilation to 1.8

Motivation:

We previously changed netty to always compile with java7 as otherwise source compatibility was broken.

This was reported in [#3548] but was fixed in the meantime:

- https://bugs.openjdk.java.net/browse/JDK-8029240

- https://bugs.openjdk.java.net/browse/JDK-8030855

Modifications:

Change minimum JDK version for compilation to 1.8

Result:

Easier to maintain code.

Change minimum JDK version for compilation to 1.8

Motivation:

We previously changed netty to always compile with java7 as otherwise source compatibility was broken.

This was reported in [#3548] but was fixed in the meantime:

- https://bugs.openjdk.java.net/browse/JDK-8029240

- https://bugs.openjdk.java.net/browse/JDK-8030855

Modifications:

Change minimum JDK version for compilation to 1.8

Result:

Easier to maintain code.

Change minimum JDK version for compilation to 1.8

Motivation:

We previously changed netty to always compile with java7 as otherwise source compatibility was broken.

This was reported in [#3548] but was fixed in the meantime:

- https://bugs.openjdk.java.net/browse/JDK-8029240

- https://bugs.openjdk.java.net/browse/JDK-8030855

Modifications:

Change minimum JDK version for compilation to 1.8

Result:

Easier to maintain code.

Change minimum JDK version for compilation to 1.8

Motivation:

We previously changed netty to always compile with java7 as otherwise source compatibility was broken.

This was reported in [#3548] but was fixed in the meantime:

- https://bugs.openjdk.java.net/browse/JDK-8029240

- https://bugs.openjdk.java.net/browse/JDK-8030855

Modifications:

Change minimum JDK version for compilation to 1.8

Result:

Easier to maintain code.

DnsNameResolver should not bind locally. Fixes #5457 Motivation: Dns resolution failures happen when using the DnsNameResolver and the JVM is not authorized to bind datagram channels. The current DnsNameResolver binds locally a DatagramChannel which is not necessary (and not always permitted).

Modifications:

The DnsNameResolver Bootstrap does not bind anymore, instead it registers and use the channel directly. The localAddress has also been removed from the DnsAddressResolverGroup, DnsNameResolver and DnsNameResolverBuilder as it is not necessary anymore and the API is marked as @UnstableApi.

Result:

Dns resolution does not require anymore to bind locally.

Share code between ReadTimeoutHandler and IdleStateHandler

Motivation:

ReadTimeoutHandler and IdleStateHandler have duplicated code, we should share whatever possible.

Modifications:

Let ReadTimeoutHandler extend IdleStateHandler.

Result:

Remove code duplication.

Share code between ReadTimeoutHandler and IdleStateHandler

Motivation:

ReadTimeoutHandler and IdleStateHandler have duplicated code, we should share whatever possible.

Modifications:

Let ReadTimeoutHandler extend IdleStateHandler.

Result:

Remove code duplication.

Fix a bug of DnsNameResolver while working with NoopDnsCache.

Motivation:

If DnsNameResolver works with NoopDnsCache, IndexOutOfBoundsException will

be thrown.

Modifications:

Test if the result of DnsNameResolver.get(hostname) is empty before

accessing it's elements.

DefaultPromise make MAX_STACK_DEPTH configurable

Motivation:

Some Netty use cases may want to configure the max allowed stack depth for promise listener notification.

Modifications:

- Add a system property so that this value can be configured.

Result:

DefaultPromise's max stack depth is configurable.

DefaultPromise make MAX_STACK_DEPTH configurable

Motivation:

Some Netty use cases may want to configure the max allowed stack depth for promise listener notification.

Modifications:

- Add a system property so that this value can be configured.

Result:

DefaultPromise's max stack depth is configurable.

HTTP/2 Decoder validate that GOAWAY lastStreamId doesn't increase

Motivation:

The HTTP/2 RFC states in https://tools.ietf.org/html/rfc7540#section-6.8 that Endpoints MUST NOT increase the value they send in the last stream identifier however we don't enforce this when decoding GOAWAY frames.

Modifications:

- Throw a connection error if the peer attempts to increase the lastStreamId in a GOAWAY frame

Result:

RFC is more strictly enforced.

Fixes #5054: IpV4Subnet.contains() always returns true for single-address subnets.

Motivation:

See #5054 and to fix remaining issue stopping Netty 3.10.6.Final being released.

Modification:

Copied IpToInt from Netty 4 and contains() functions.

Result:

Now issue #5054 shown examples are doing what they are expected to do.