Motivation:
Having composite buffer as a class has caused problems in the past.
Making it an interface makes it possible to stub or decorate the composite buffer implementation.
Modification:
Make CompositeBuffer an interface, and move the implementation to DefaultCompositeBuffer.
Then hide the implementation and permit construction only through static factory methods.
Result:
CompositeBuffer is now an interface.
Motivation:
The bom shouldnt depend on the parent as it may define extra dependencies that would be "pulled" in.
See https://github.com/netty/netty/pull/11672#discussion_r707619462
Modifications:
- Revert commit d6383bf2478267eb62b1f71807c2a3c34794d1b0.
- Add tcnative version and add comments to ensure we keep the version in-sync
Result:
Correct bom for netty
Motivation:
It may in some cases be useful to unwrap a composite buffer and work on the array of buffers directly.
The decomposeBuffer method makes this possible safely, by killing the composite buffer in the process.
Modification:
Add a CompositeBuffer.decomposeBuffer method, which returns the array of the constituent component buffers of the composite buffer, and at the same time closes the composite buffer without closing its components.
The caller effectively takes ownership of the component buffers away from the composite buffer.
Result:
This API makes buffer composition fully reversible.
Motivation:
The "used memory" is the amount of memory that a pooled allocator has currently allocated and committed for itself.
Ths is useful for managing resource usage of the pool versus the available system resources.
However, it is not useful for managing resources of the currently circulating buffer instances versus the pool.
The pinned memory is the memory currently in use by buffers in circulation, plus memory held in the thread-local caches.
Modification:
Add pinned memory accounting to PoolChunk.
We cannot just use the existing freeBytes because that field is only updated when pool subpages are retired, and a chunk will never retire its last subpage instance.
The accounting statistics are available on the PooledByteBufAllocator only, since the metrics interfaces cannot be changed due to backwards compatibility.
Result:
It is now possible to get a fairly accurate (with slight over-counting due to the thread-local caches) picture of how much memory is held up in buffer instances at any given moment.
Fixes#11637
__Motivation__
In order to migrate all codec incrementally to use `Buffer`, we need a version of `ByteToMessageDecoder` that uses `Buffer`.
__Modification__
- Added the new version of `ByteToMessageDecoder` with a new name so that both old and new version can co-exist and we can incrementally migrate all codecs
- Migrated `FixedLengthFrameDecoder` as it was simple and used in tests.
__Result__
We have the basic building block to start migrating all codecs to the new `Buffer` API.
Motivation:
We only implement cpu_relax() for x86_64 atm, we should also do for aarch64
Modifications:
Add implementation
Result:
Possible better performance on aarch64 when busy spinning with epoll is used
Motivation:
netty-tcnative 2.0.42.Final did not include all native libs due a problem during the release. This was fixed with the new release.
Modifications:
Upgrade to 2.0.43.Final
Result:
Depend on a netty-tcnative version that includes all native libs.
__Motivation__
While computing offsets from within `CompositeBuffer#split()`, we do not consider a case when the constituents `buffer` array is empty but existing read/write offsets are non-zero. This is possible when the buffer is full.
__Modification__
Correctly set offsets even for the aforementioned case.
__Result__
Read/write offsets are correctly set while splitting composite buffer.
Motivation:
Netty's bom includes netty-tcnative dependencies with a variable for the
version [1]. However that variable isn't defined/resolved and therefore
leads to undefined dependencies.
[1] https://search.maven.org/artifact/io.netty/netty-bom/4.1.68.Final/pom
Modifications:
- Netty's bom file should inherit from netty-parent pom so variables can
be resolved at inclusion time.
Result:
netty-bom allows for netty-tcnative version to be resolved in 3rd party
projects.
Motivation:
We did use the incorrect classifier and also missed to add the osx-aarch_64 version of netty-tcnative-boringssl-static
Modifications:
Fix entries
Result:
Correct and complete bom
Motivation:
e Snappy frame decoder function doesn't restrict the size of the compressed data (and the uncompressed data) which may lead to excessive memory usage. Beside this it also may buffer reserved skippable chunks until the whole chunk was received which may lead to excessive memory usage as well.
Modifications:
- Add various validations for the max allowed size of a chunk
- Skip bytes on the fly when an skippable chunk is handled
Result:
No more risk of OOME. Thanks to Ori Hollander of JFrog Security for reporting the issue.
Motivation:
We should do the Bzip2 decoding in a streaming fashion and so ensure we propagate the buffer as soon as possible through the pipeline. This allows the users to release these buffers as fast as possible.
Modification:
- Change the Bzip2Decoder to do the decompression of data in a streaming fashion.
- Add some safety check to ensure the block length never execeeds the maximum (as defined in the spec)
Result:
No more risk of an OOME by decompress some large data via bzip2.
Thanks to Ori Hollander of JFrog Security for reporting the issue.
(we got acquired during the process and now Vdoo is part of JFrog company)
Motivation:
When using the JDK implementation for SSL its possible to adjust the used named groups. We should allow to do this as well and also select some default groups that will reduce the number of roundtrips.
Modifications:
- Upgrade netty-tcnative so we can set the curves
- Respect jdk.tls.namedGroups
- Use default groups of "P-256", "P-384", "X25519" so its compatible with what the JDK versions < 13 support as well.
Result:
Be able to set the used groups
Co-authored-by: Nitesh Kant <nitesh_kant@apple.com>
Motivation:
As more and more people switch to a mac m1 we should support it
Modifications:
- Add profiles for cross-compile for mac m1
- Adjust script to finish release
Result:
Mac m1 is supported
Motivation:
Accessing the native address, if a buffer has any, violates the no-aliasing rule for Buffers.
Also, it inherently assumes that a buffer has a single, native memory allocation.
The native address, or addresses, are already available via the Readable- and WritableComponents.
Accessing these via forEachReadable and forEachWritable will also ensure that composite buffers will be handled correctly.
Modification:
Remove the nativeAddress() method from the Buffer API.
Update the ByteBufAdaptor and a few tests to cope with this change.
Result:
Less error prone code, and make unsafe APIs a bit more hidden.
Motivation:
Currently, Netty is silently truncating all over the limit UDS paths and ignoring the `sun_path`'s null-termination role, which hurts compatibility with other UDS clients and servers.
Modifications:
Adding a validation in the JNI code, if the UDS path is not satisfying the system limit or Linux spec throw a NativeIoException.
Result:
All UDS paths Netty can successfully bind are connectable by other programs.
Motivation:
It is important to avoid blocking method calls in an event loop thread, since that can stall the system.
Netty's Future interface was extending the JDK Future interface, which included a number of blocking methods of questionable use in Netty.
We wish to reduce the number of blocking methods on the Future API in order to discourage their use a little.
Further more, the Netty Future specification of the behaviour of the cancel() and isDone() methods are inconsistent with those of the JDK Future.
If Netty's Future stop extending the JDK Future interface, it will also no longer be bound by its specification.
Modification:
Make Netty's Future no longer extend the JDK Future interface.
Change the EvenExecutorGroup interface to no longer extend ScheduledExecutorService.
The EventExecutorGroup still extends Executor, because Executor does not dictate any return type of the `execute()` method — this is also useful in the DefaultFutureCompletionStage implementation.
The Netty ScheduledFuture interface has been removed since it provided no additional features that were actually used.
Numerous changes to use sites that previously relied on the JDK types.
Remove the `Future.cancel()` method that took a boolean argument — this argument was always ignored in our implementations, which was another spec deviation.
Various `invoke*` and `shutdown*` methods have been removed from the EvenExecutorGroup API since it no longer extends ScheduledExecutorService — these were either not used anywhere, or deprecated with better alternatives available.
Updates to cancellation javadocs.
Result:
Cleaner code, leaner API.
Motivation:
People might be tempted to use mocking tools like Mockito.spy() on the ByteCursors.
By returning instances where the concrete classes are final, we will be forcing integrators to use stub-like wrappers instead.
Such stubs are more well-behaved since they are implemented in terms of the real instance.
This prevents the mocked objects from (easily) producing behaviour that violates the API specification.
Modification:
All ByteCursor implementations have changed from using anonymous inner classes, to using static-final named inner classes.
Result:
The concrete ByteCursor classes can no longer be extended via byte code generation, such as from mocking tools.
Motivation:
While using netty there is sometimes need to handle the cipher suites and
signature algorithm in more strict environment. CipherSuiteConverter is
quite helpful in converting Cipher-Suites to and from java to openSSL.
Making it public would be helpful for the project which are using netty.
Modification:
Updated "CipherSuitesConverter" to make it public.
updated "CipherSuitesConverter.toOpenssl" to public.
updated "CipherSuitesConverter.toJava" to public.
Result:
Fixes#11655
Motivation:
We can remove some classes and duplication if we add default methods
Modifications:
- Add default methods to EventExecutor / EventExecutorGroup / EventLoop / EventLoopGroup
- Remove code duplication
- Remove AbstractEventExecutorGroup as it is not needed anymore
Result:
Cleanup and removal of code-duplication. Also makes it easier for people to implement their custom executors / groups
__Motivation__
As we start to migrate codecs to use the new `Buffer` API, we need a way for them to get a handle of `BufferAllocator`.
__Modification__
Added `bufferAllocator()` method to `ChannelConfig`, `Channel` and `ChannelHandlerContext`
__Result__
Codecs can allocate `Buffer` instances
Motivation:
The way how an EventLoopGroup is created for a specific transport has changed. We should remove all the old deprecated implementations and change all our code to use the new way how to init groups
Modifications:
- Remove LocalEventLoopGroup, NioEventLoopGroup, EpollEventLoopGroup and KQueueEventLoopGroup
- Adjust code to use the new way how to setup EventLoopGroups
Result:
Remove deprecate classes and usages
Motivation:
When users receive "Maximum active streams violated for this endpoint"
exception, it's useful to know what is the current max streams limit on
HTTP/2 connection.
Modifications:
- Include current number of maximum active streams in exception message;
Result:
Easier debugging of HTTP/2 connections.
Motivation:
When the ByteBuf size exceeds the max limit/defined size, IOException is thrown.
HttpData#addContent/setContent should release the buffer in such cases otherwise memory leak will happen.
Modification:
- Release the provided ByteBuf before throwing IOException
- Add unit tests
Result:
Fixes#11618
Motivation:
There are some redundant imports and unnecessary type cast
Modification:
Remove useless imports and unnecessary type cast
Result:
The code is cleaner than original
Signed-off-by: xingrufei <xingrufei@sogou-inc.com>
Motivation:
Exception logged by `onHttp2UnknownStreamError` is propagated to the
upper layers anyway. Receiver of the exception is responsible for
correct handling. Inside netty, it's enough to log at `DEBUG` level.
Modifications:
- `Http2FrameCodec#onHttp2UnknownStreamError` always logs at `DEBUG`
level;
Result:
Less noise in logs when `Http2UnknownStreamError` is properly handled by
upper layers.
Co-authored-by: Norman Maurer <norman_maurer@apple.com>
Co-authored-by: Chris Vest <mr.chrisvest@gmail.com>
Motivation:
While we use DefaultPromise as our implementation of Promise and Future users should not really use it directly. Users should always use the EventExecutor / EventLoop to create a Promise / Future.
Modifications:
- Change static Promise methods to be package-private
- Add default implementations for Promise and Future creation to EventExecutor
- Change public constructor to protected
- Remove usage of DefaultPromise in our tests
Result:
Less likely users will depend on the actual Promise implementation
Motivation:
We wish to separate these two into clearer write/read interfaces.
In particular, we don't want to be able to add listeners to promises, because it makes it easy to add them out of order.
We can't prevent it entirely, because any promise can be freely converted to a future where listeners can be added.
We can, however, discourage this in the API.
Modification:
The Promise interface no longer extends the Future interface.
Numerous changes to make the project compile and its tests run.
Result:
Clearer separation of concerns in the code.
Motivation:
Enlarging buffers approaching 4 MiB size requires n iterations
Modification:
Use a single instruction to compute the next buffer capacity
Result:
Faster/Simpler calculateNewCapacity
Motivation:
Last time when we tried to do a release it failed due the fact that no javadoc jar was generated. Beside this how we did configure the shading module did introduce a lot of duplication
Modifications:
- Generate an empty javadoc jar
- Share config for shading plugin
Result:
No more problems during release process
Motivation:
If we don't need the scheduled future, then it will be one less complication when we change Netty Future to no longer extend JDK Future.
It would also result in fewer elements in our API.
Modification:
There was only one real use of ScheduledFuture in our code, in Cache.
This has been changed to wrap an ordinary future with a deadline for implementing the Delayed interface.
All other places were effectively overspecifying by relying on ScheduledFuture.
A few places were also specifying JDK Futures - these have been changed to specify Netty Futures.
Result:
Reduced dependency on the ScheduledFuture interfaces.
Motivation:
Usually the outbound operation should start at the "current" ChanneöHandlercontext which was often not the case
Modifications:
Use the ChannelHandlerContext for closing the connection
Result:
Start the operation on the right position of the pipeline
Motivation:
There is a memory leak while writing empty data frame with padding.
The empty data frame was occurred because we are running a proxy server
built by netty, and found that google services always sent data frames
followed by an empty data frame.
Modifications:
Calls the ctx.write even the payload is empty.
Result:
Fix memory leak.
Co-authored-by: Norman Maurer <norman_maurer@apple.com>
Motivation:
DiskFileUpload#toString should use the value provided when constructing DiskFileUpload
and not the default one
Modification:
- DiskFileUpload#toString is modified to use the correct deleteOnExit value
Result:
DiskFileUpload#toString returns a string that uses the correct deleteOnExit
Motivation:
When we override a test with params we also need to ensure we add the correct annotations to the override
Modifications:
Add the correct annotations so the tests are actually run in intellij
Result:
Each test can be run
Motivation:
While OpenSSK is provided support for the "RSASSA-PSS" algorithm this was still not valid from netty. Which was causing issue in validating certificates which was signed using this algorithm.
Modification:
Added "RSASSA-PSS" in LOCAL_SUPPORTED_SIGNATURE_ALGORITHMS.
validation:
Validated and tested with CA and User cert singed with RSASSA-PSS algorithm.
Result:
Fixes#11360
Co-authored-by: Norman Maurer <norman_maurer@apple.com>
Motivation:
We should not use master as branch name, better to switch to main
Modifications:
Replace master branch name with main
Result:
Use main as replacement for master
Motivation:
We did recently change the Channel / ChannelHandler API to always act on the Future only. We should do the same for our handlers.
Modifications:
- Adjust http2 API
- Adjust other handlers API
Result:
Easier to use API and more consistent
Motivation:
Our current ChannelFutureListeners are too restrictive in terms of the type of the context. We should lift this a bit
Modifications:
Refactor ChannelFutureListeners to not be an enum and so allow most of its instances to be used with any ChannelOutboundInvoker.
Result:
More flexible usage
Motivation:
The need of cascade from a Future to a Promise exists. We should add some default implementation for it.
Modifications:
- Merge PromiseNotifier into Futures
- Add default cascadeTo(...) methods to Future
- Add tests to FuturesTest
- Replace usage of PromiseNotifier with Future.cascadeTo
- Use combination of map(...) and cascadeTo(...) in *Bootstrap to reduce code duplication
Result:
Provide default implementation of cascadeTo.
Motivation:
In this issue(#11578 ) discussed that tilde should not be encoded in QueryStringEncoder, this pr is to fix this problem
Modification:
Modified QueryStringEncoder so that it does not encode tilde, and added a test case
Result:
Fixes#11578
Motivation:
Making futures easier to compose, combine, and extend is useful to have as part of the API, since implementing this correctly and efficiently can be tricky.
Modification:
Add `Future.map(Function<V,R>) -> Future<R>` and `Future.flatMap(Function<V,Future<R>>) -> Future<R>` default methods to the `Future` interface.
These methods return new Future instance, that will be completed when the original future completes, and the result will be processed through the given mapping function.
These two methods take care to propagate cancellation and exceptions correctly:
Cancellation propagates both ways between the new and original future.
Failures only propagate from the original future to the returned new Future instance.
Result:
A few convenient methods for modifying and composing futures.
This PR fixes#8523, and perhaps also #2105
Motiviation:
The workflow from the default branch is the one that gets to run for all PRs, regardless of what branch they are targeting.
This means the 4.1 PR Reports workflow needs to tollerate master branch PRs, where there is no Java 8 builds.
Modification:
Make the PR Reports tolerate that the Java 8 matrix fails if they are missing.
Result:
Hopefully we'll get working PR Reports for master branch PRs now.
Motivation:
The expression "not is success" can mean that either the future failed, or it has not yet completed.
However, many places where such an expression is used is expecting the future to have completed.
Specifically, they are expecting to be able to call `cause()` on the future.
It is both more correct, and semantically clearer, to call `isFailed()` instead of `!isSuccess()`.
Modification:
Change all places that used `!isSuccess()` to mean that the future had failed, to use `isFailed()`.
A few places are relying on `isSuccess()` returning `false` for _incomplete_ futures, and these places have been left unchanged.
Result:
Clearer code, with potentially fewer latent bugs.
Motivation:
We did miss to update some code that setup the EventLoop mock and so did see test-failures due NPE's
Modifications:
Correctly mock the newPromise() method.
Result:
No more test-failures
Motivation:
232c669fa4 did add some overflow protection but did not handle null elements in the array the same as before.
Modifications:
- Break the loop if a null element was found
- Add unit test
Result:
Fixes https://github.com/netty/netty/issues/11612
