Commit Graph

30 Commits

Author SHA1 Message Date
Norman Maurer
a873932985
Remove deprecated Channel*Handler* classes (#11615)
* Remove deprecated Channel*Handler* classes

Motivation:

There is no need to keep the older adapter and duplex classes around.

Modifications:

- Remove old adapter and duplex classes
- Adjust javadocs

Result:

Cleanup

* Address nit
2021-08-25 19:04:32 +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
Norman Maurer
89866da252 Add CI job for JDK17 (#11584)
Motivation:

As JDK17 is really close to be released we should add a CI job for it to ensure netty works correctly when using it.

Modifications:

Add docker config and workflow config to run CI job for JDK17

Result:

Ensure netty works on JDK17 as well
2021-08-18 10:13:20 +02:00
Chris Vest
6a92a3354e Use the standard japicmp.skip instead of the custom skipJapicmp (#11558) 2021-08-10 09:07:04 +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
Riley Park
fd111e22d9
Migrate transport-blockhound-tests tests to JUnit 5 (#11322)
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 16:00:30 +02:00
Norman Maurer
c56e5e6e4f Fail the build if we can't load the OpenSSL library (#11269)
Motivation:

We should better fail the build if we can't load the OpenSSL library to ensure we not introduce a regression at some point related to native library loading

Modifications:

Remove usages of assumeTrue and let the tests fail if we cant load the native lib

Result:

Ensure we not regress
2021-05-19 11:03:01 +02:00
Norman Maurer
b41891b602 Skip deployment of testsuite jars (#11127)
Motivation:

We should skip the deployment of jars that are not meant to be consumed by the user as there is no public API.

Modifications:

Let's skip deployment for modules that are not useful for users

Result:

Build cleanup
2021-03-30 19:06:34 +02: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
Norman Maurer
ede5eecf35 Fix compile error introduced by dd89d1b6bf 2021-01-14 18:56:32 +01:00
Violeta Georgieva
dd89d1b6bf Allow blocking calls in UnixResolverDnsServerAddressStreamProvider#parse (#10935)
Motivation:

Internally UnixResolverDnsServerAddressStreamProvider#parse calls FileInputStream.read(...)
when parsing the etcResolverFiles.
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 entry to BlockHound configuration
- Add test

Result:

Fixes #10925
2021-01-14 18:33:26 +01:00
Violeta Georgieva
4c86fbd967 Add whitelist entry for SSLEngineImpl.wrap to BlockHound configuration (#10844)
Motivation:

Internally SSLEngineImpl.wrap(...) may call FileInputStream.read(...).
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 entry to BlockHound configuration
- Add test

Result:

Fixes #10837
2020-12-07 08:21:18 +01:00
Alexandre Dutra
aab4c0c78a Allow blocking calls inside SingleThreadEventExecutor.addTask (#10811)
Motivation:

GlobalEventExecutor.addTask was rightfully allowed to block by commit
09d38c8. However the same should have been done for
SingleThreadEventExecutor.addTask.

BlockHound is currently intercepting that call, and as a consequence,
it prevents SingleThreadEventExecutor from working properly, if addTask is
called from a thread that cannot block.

The interception is due to LinkedBlockingQueue.offer implementation,
which uses a ReentrantLock internally.

Modifications:

* Added one BlockHound exception to
io.netty.util.internal.Hidden.NettyBlockHoundIntegration for
SingleThreadEventExecutor.addTask.
* Also added unit tests for both SingleThreadEventExecutor.addTask
and GlobalEventExecutor.addTask.

Result:

SingleThreadEventExecutor.addTask can now be invoked from any thread
when BlockHound is activated.
2020-11-23 19:27:19 +01:00
Alexandre Dutra
cb7d38b0dc Allow blocking calls inside HashedWheelTimer start() and stop() (#10810)
Motivation:

When a HashedWheelTimer instance is started or stopped, its working
thread is started or stopped. These operations block the calling
thread:
- start() calls java.util.concurrent.CountDownLatch.await() to wait
for the worker thread to finish initializing;
- stop() calls java.lang.Thread.join(long) to wait for the worker
thread to exit.
BlockHound detects these calls and as a consequence, prevents
HashedWheelTimer from working properly, if it is started or stopped
in a thread that is not allowed to block.

Modifications:

Added two more BlockHound exceptions to
io.netty.util.internal.Hidden.NettyBlockHoundIntegration: one
for HashedWheelTimer.start() and one for HashedWheelTimer.stop().

Result:

HashedWheelTimer can now be started and stopped properly when
BlockHound is activated.
2020-11-23 11:19:44 +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
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
Chris Vest
6201c6d80f
Add a build profile for JDK 16 (#10675)
Motivation:
Java 16 will come around eventually anyway, and this makes it easier for people to experiment with Early Access builds.

Modification:
- Added Maven profiles for JDK 16 to relevant pom files.
- Removed the `--add-exports java.base/sun.security.x509=ALL-UNNAMED` argument when running tests; we've not needed it since the Java11-as-baseline PR landed.

Result:
Netty now builds on JDK 16 pre-releases (provided they've not broken compatibility in some way).
2020-10-12 16:42:40 +02:00
Chris Vest
a179db8066
Raise the Netty 5 minimum required Java version to Java 11. (#10650)
Raise the Netty 5 minimum required Java version to Java 11.

Motivation:
Java 11 has been out for some time, and Netty 5 is still some ways out.
There are also many good features in Java 11 that we wish to use, such as VarHandles, var-keyword, and the module system.
There is no reason for Netty 5 to not require Java 11, since Netty 4.x will still be supported for the time being.

Modification:
Remove everything in the pom files related to Java versions older than Java 11.
Remove the animal-sniffer plug-in and rely on the `--release` compiler flag instead.
Remove docker files related to Java versions older than Java 11.
Remove the copied SCTP APIs -- we should test this commit independently on Windows.
Remove the OpenJdkSelfSignedCertGenerator.java file and just always use Bouncy Castle for generating self-signed certificates for testing.
Make netty-testsuite tests pass by including Bouncy Castle as a test dependency, so we're able to generate our self-signed certificate.

Result:
Java 11 is now the minimum required Java version.
2020-10-12 14:13:01 +02:00
violetagg
269896da13 When BlockHound is installed, do not report GlobalEventExecutor/SingleThreadEventExecutor#takeTask as blocking call. (#10020)
Motivation:

GlobalEventExecutor/SingleThreadEventExecutor#taskQueue is BlockingQueue.

Modifications:

Add allowBlockingCallsInside configuration for GlobalEventExecutor/SingleThreadEventExecutor#takeTask.

Result:

Fixes #9984
When BlockHound is installed, GlobalEventExecutor/SingleThreadEventExecutor#takeTask is not reported as a blocking call.
2020-08-12 09:15:10 +02:00
Norman Maurer
6fd5550ad7 Add whitelist entry to BlockHound config to workaround issue when TLS… (#10459)
Motivation:

SSLEngineImpl.unwrap(...) may call FileInputStream.read(...) internally when TLS1.3 is used. This will cause an BlockingOperationError when BlockHound is enabled.

For more details see https://mail.openjdk.java.net/pipermail/security-dev/2020-August/022271.html

Modifications:

- Add whitelist entry to BlockHound config for now
- Update NettyBlockHoundIntegrationTest to include testing for this workaround

Result:

No BlockingOperationError when TLS1.3 is used with JDK SSL implementation and BlockHound is enabled
2020-08-10 11:12:52 +02:00
violetagg
f9e8c9ca11 Do not report ReferenceCountedOpenSslClientContext$ExtendedTrustManagerVerifyCallback.verify as blocking call (#10387)
Motivation:

When BlockHound is installed,
ReferenceCountedOpenSslClientContext$ExtendedTrustManagerVerifyCallback.verify
is reported as blocking call.

Modifications:

Add allowBlockingCallsInside configuration for
ReferenceCountedOpenSslClientContext$ExtendedTrustManagerVerifyCallback.verify

Result:

Fixes #10384
2020-07-06 09:36:00 +02:00
Norman Maurer
760de7dde4 Hardcode TLS version used during blockhound tests (#10162)
Motivation:

Different versions of the JDK use different TLS versions by default. We should define the versions explicit

Modifications:

Explicit specify TLSv1.2

Result:

Blockhound tests pass on JDK14 as well
2020-04-03 14:49:14 +02:00
Norman Maurer
ff9667b1f9 Add profile to build on JDK 14 (#10148)
Motivation:

JDK 14 was released and need some special settings to be able to build with. Also there seems to be one regression that we need to workaround for now.

Modifications:

- Add maven profile for JDK 14
- Update blockhound version to be able to work on JDK 14
- Add workaround for possible JDK 14 regression

Result:

Be able to build on JDK 14
2020-03-31 16:03:10 +02:00
Norman Maurer
2c3833472a Update to Blockhound 1.0.2 (#10007)
Motivation:

A new version of blockhound was released today

Modifications:

Upgrade to latest blockhound version

Result:

Use latest blockhound release
2020-02-08 17:04:51 +01:00
Johno Crawford
7413372c01 SSL / BlockHound works out of the box with the default SSL provider (#9969)
Motivation:

JDK is the default SSL provider and internally uses blocking IO operations.

Modifications:

Add allowBlockingCallsInside configuration for SslHandler runAllDelegate function.

Result:

When BlockHound is installed, SSL works out of the box with the default SSL provider.

Co-authored-by: violetagg <milesg78@gmail.com>
2020-01-30 11:50:15 +01:00
Sergei Egorov
6591a6501c Test that NettyBlockHoundIntegration can be loaded with ServiceLoader (#9743)
Motivation:

If something is mis-configured, the "main" test will fail but it is unclear
whether it fails because the integration does not work or it wasn't applied
at all.
Also see:
https://github.com/netty/netty/issues/9738#issuecomment-548416693

Modifications:

This change adds a test that uses the same mechanism as BlockHound does
(`ServiceLoader`) and checks that `NettyBlockHoundIntegration` is present.

Result:

It is now clear whether the integration is not working or it wasn't loaded at all.
2019-11-01 07:07:59 +01:00
Sergei Egorov
17cff0ee77 Make BlockHound tests run on Java 13 (#9742)
Motivation:
Java 13 requires special flags to be set to make BlockHound work

Modifications:
- Added jdk13 profile to `transport-blockhound-tests`
- Enabled `-XX:+AllowRedefinitionToAddDeleteMethods` on jdk13

Result:
The tests work on Java 13
2019-11-01 07:05:09 +01:00
Norman Maurer
5949e193ce Fix compilation error introduced by 2854c2c473 2019-10-25 17:47:27 +02:00
Sergei Egorov
2854c2c473 Add BlockHound integration that detects blocking calls in event loops (#9687)
Motivation:

Netty is an asynchronous framework.
If somebody uses a blocking call inside Netty's event loops,
it may lead to a severe performance degradation.
BlockHound is a tool that helps detecting such calls.

Modifications:

This change adds a BlockHound's SPI integration that marks
threads created by Netty (`FastThreadLocalThread`s) as non-blocking.
It also marks some of Netty's internal methods as whitelisted
as they are required to run the event loops.

Result:

When BlockHound is installed, any blocking call inside event loops
is intercepted and reported (by default an error will be thrown).
2019-10-25 15:14:44 +02:00