[DO NOT MERGE] Upgrades Netty to 4.1.132#39
Open
tiagomlalves wants to merge 127 commits intodse-netty-4.1.128from
Open
[DO NOT MERGE] Upgrades Netty to 4.1.132#39tiagomlalves wants to merge 127 commits intodse-netty-4.1.128from
tiagomlalves wants to merge 127 commits intodse-netty-4.1.128from
Conversation
Backport of netty#15752 Motivation: Reflective field accesses were initially disabled in netty#10428 because back then native-image did not support `Unsafe.staticFieldOffset()`. This is no longer an issue since GraalVM 21.2.0 for JDK 11 (July 2021) see oracle/graal@f97bdb5 Modification: Remove the check for native-image before accessing fields using `Unsafe`. Result: Netty can directly access fields necessary for `PlatformDependent0` initialization using `Unsafe`.
Motivation: There are JDK updates we should use them Modifications: - Update JDK versions Result: Use latest JDK versions
Motivation: An invalid content length in a continue request would induce HttpObjectAggregator to throw a NumberFormatException. Modification: Use the existing isContentLengthInvalid to guard the getContentLength call in continue request processing. Result: No exception thrown.
…etty#15798) Motivation: The consumeCPU call can disturb potential optimizations, so its desirable to be able to benchmark the case where it's not present. Modification: Add a zero-delay parameter to the benchmark, and make sure the consumeCPU call is skipped in that case. Result: More flexible benchmark.
Motivation: When the padding of an HTTP/2 DATA frame exceeds the bounds of the frame, an IndexOutOfBoundsException would be thrown instead of the expected Http2Exception: ``` Exception in thread "main" java.lang.IndexOutOfBoundsException: readerIndex: 1, writerIndex: 0 (expected: 0 <= readerIndex <= writerIndex <= capacity(4)) at io.netty.buffer.AbstractByteBuf.checkIndexBounds(AbstractByteBuf.java:112) at io.netty.buffer.AbstractByteBuf.writerIndex(AbstractByteBuf.java:135) at io.netty.buffer.WrappedByteBuf.writerIndex(WrappedByteBuf.java:132) at io.netty.handler.codec.http2.DefaultHttp2FrameReader.readDataFrame(DefaultHttp2FrameReader.java:408) at io.netty.handler.codec.http2.DefaultHttp2FrameReader.processPayloadState(DefaultHttp2FrameReader.java:244) at io.netty.handler.codec.http2.DefaultHttp2FrameReader.readFrame(DefaultHttp2FrameReader.java:164) ``` Modification: Instead of verifying the padding size against the full payloadLength, which includes the pad length, move the check to lengthWithoutTrailingPadding where the exact number of remaining bytes is known. Result: Proper protocol error. Co-authored-by: Jonas Konrad <jonas.konrad@oracle.com>
Motivation: BlockHound version 1.0.15.RELEASE comes with newer byte-buddy dependency Modification: - Bump BlockHound version as byte-buddy dependency is updated Result: BlockHound version 1.0.15.RELEASE with newer byte-buddy dependency
…ty#15800) Motivation: I've gotten allocation profile data from "a large e-commerce application", which has sizable allocation volume at 32 KiB and 64 KiB, with very little in between that isn't covered by the existing size classes. Modification: Add 32 KiB and 64 KiB size classes to the adaptive allocator. Make the adaptiveChunkMustDeallocateOrReuseWthBufferRelease test more size-class agnostic. Result: Nearly 50% memory usage reduction in this e-commerce application use case, according to the allocation pattern simulator for the 1024 live buffers case, which brings adaptive on par with the pooled allocator for this use case. Co-authored-by: Chris Vest <christianvest_hansen@apple.com>
(… (netty#15810) …netty#15805) Motivation: Fixes netty#15804. In java 25, some mqtt flows cause `IndexOutOfBoundsException` as unsafe is no longer used. Modification: Use `MqttEncoder.writeEagerUTF8String` which precalculates expected buffer size instead of `MqttEncoder.writeUnsafeUTF8String`. Result: No more IndexOutOfBoundsException in MqttEncoder and Java 25 Co-authored-by: Dmytro Dumanskiy <doom369@gmail.com>
Motivation: If the ByteToMessageDecoder gets a reentrant channelRead call, we need to avoid closing or otherwise manipulating the cumulation buffer. Modification: Guard reentrant channelRead calls by queueing up messages and letting the top-level call process them all in order. Result: Reentrant calls to ByteToMessageDecoder.channelRead will no longer cause weird IllegalReferenceCountException on the cumulation buffer.
Motivation: Comment on the sizeId2sizeTab table looks like it's referencing wrong field, going by how its created and used. Modification: Make it reference the nSizes field, which is used in the computation of the table. Result: Clearer comment. Fixes netty#15333
…5846) Motivation: AsciiString should have a consistent hash code regardless of the platform we're running on, because we don't know of the hash code gets exposed or used across platforms. An optimized version of the hash code was assuming a little-endian platform but could end up being used on big endian platforms. Modification: Add a condition that the safe, platform-agnostic hash code implementation should be used on big endian platforms. Result: The AsciiString hash code values are now always the same regardless of the platform and JVM configuration we're running on.
Motivation: GitHub has deprecated the macOS 13 runners and will be removing them. Details in actions/runner-images#13046 Modification: Replace the runner OS for all Intel Mac builds with macos-15-intel. Result: MacOS builds now run on the latest and last version of MacOS that will have Intel support.
Motivation: Better javadoc for `CompositeByteBuf#release` method Modification: Add javadoc Result: Fixes netty#15863 --------- Co-authored-by: Norman Maurer <norman_maurer@apple.com>
Motivation: The `AbstractHttp2StreamChannel` subclasses use a synthetic id in their `ChannelId`, but include the real stream id in their `toString()` method. Using two different ids makes it harder to correlate the two in logs. The synthetic ids are necessary because the stream id is assigned at a protocol level at some point after the channel has been created. Modification: Include the synthetic id in the `AbstractHttp2StreamChannel.toString()` output. Result: Easier to correlate HTTP/2 channel and stream ids, to help with debugging.
### Motivation The failure was found with [NonDex](https://github.com/TestingResearchIllinois/NonDex), which explores non-determinism in tests. These tests can cause test failure under different JVMs, etc. The non-determinism in the test class `io.netty.handler.codec.http.websocketx.extensions.WebSocketExtensionUtilTest` in `codec-http` module is caused by the `WebSocketExtensionUtil` storing extension parameters in a HashMap, whose iteration order is nondeterministic. When `computeMergeExtensionsHeaderValue` serializes these parameters using `data.parameters().entrySet()`, the output ordering varies depending on the underlying hash iteration order. #### Modifications Replacing the parameter hashmaps with `LinkedHashMap` fixes the issue by preserving deterministic insertion/iteration order. ### Result After the 3-line modification, the tests no longer depend on non-deterministic order of HashMap iteration. ### Failure Reproduction 1. Checkout the 4.2 branch and the recent commit I tested on: 0a3df28 2. Environment: > openjdk 17.0.16 2025-07-15 OpenJDK Runtime Environment (build 17.0.16+8-Ubuntu-0ubuntu124.04.1) OpenJDK 64-Bit Server VM (build 17.0.16+8-Ubuntu-0ubuntu124.04.1, mixed mode, sharing) > Apache Maven 3.9.11 3. Run test with [NonDex](https://github.com/TestingResearchIllinois/NonDex), for example: ``` mvn -pl codec-http edu.illinois:nondex-maven-plugin:2.1.7:nondex \ -Dtest=io.netty.handler.codec.http.websocketx.extensions.WebSocketExtensionUtilTest#computeMergeExtensionsHeaderValueWhenNoConflictingUserDefinedHeader \ -DnondexRerun=true -DnondexRuns=1 -DnondexSeed=974622 \ -Djacoco.skip -Drat.skip -Dpmd.skip -Denforcer.skip ``` 4. Observe the test failure Co-authored-by: lycoris106 <53146702+lycoris106@users.noreply.github.com>
netty#15894) …size (netty#15859) Motivation: If the size of the input buffer is smaller than the configured block size (64 KB by default), then ZstdEncoder.write only produces an empty buffer. With the default sizes, this makes the encoder unusable for variable size content. This is for fixing the issue(netty#15340) Modification: Return the uncompressed data if for small size data Result: Fixes netty#15340 Signed-off-by: xingrufei <qhdxssm@qq.com> Co-authored-by: skyguard1 <qhdxssm@qq.com>
Motivation: Zstd compression fails for sources larger than 31MB since the default max encode size is 32M. This is PR is to change default max encode size to `Integer.MAX_VALUE` so that `ZstdEncoder` can works for large data Modification: Change default max encode size to `Integer.MAX_VALUE` so that `ZstdEncoder` can works for large data Result: Fixes netty#14972 `ZstdEncoder` can works for the large data Signed-off-by: xingrufei <qhdxssm@qq.com> Signed-off-by: skyguard1 <qhdxssm@qq.com> Co-authored-by: skyguard1 <qhdxssm@qq.com>
netty#15916) …netty#15911) Motivation: The splice implementation was quite buggy and also not really fits in the whole pipeline idea so we removed it already for 5.x. Let's mark it as deprecated as well in earlier versions. Modifications: Add deprecation to methods Result: Prepare users that these methods / functionallity will go away
… (netty#15917) Motivation: We used Bootstrap to bootstrap EpollServerSocketChannel in the test which is not correct. Modification: Use ServerBootstrap Result: Correct bootstrap used in test
…nEventLoop() results (netty#15927) ## Motivation A race condition exists in `NonStickyEventExecutorGroup.NonStickyOrderedEventExecutor` that can cause `inEventLoop()` to return incorrect results, potentially leading to deadlocks and synchronization issues. ## Modifications - Restore `executingThread` in the exception handler before setting `state` to `RUNNING` in `common/src/main/java/io/netty/util/concurrent/NonStickyEventExecutorGroup.java:262` - Add test `testInEventLoopAfterReschedulingFailure()` to verify `inEventLoop()` returns true after failed reschedule attempt ## Result The executor correctly maintains `executingThread` even when rescheduling fails, and `inEventLoop()` consistently returns accurate results. ## Details When the executor processes `maxTaskExecutePerRun` tasks and needs to reschedule itself, if `executor.execute(this)` throws an exception (e.g., queue full), the catch block previously reset `state` to `RUNNING` but did not restore `executingThread`, leaving it `null`. This fix ensures `executingThread.set(current)` is called before `state.set(RUNNING)` to maintain the invariant that when `state == RUNNING`, the executing thread is properly tracked. ## Testing The new test `testInEventLoopAfterReschedulingFailure()` has been verified to fail without the fix and pass with the fix applied.
Motivation: lz4-java has been discontinued (see [README](https://github.com/lz4/lz4-java)) and I've forked it to fix [CVE-2025-12183](https://sites.google.com/sonatype.com/vulnerabilities/cve-2025-12183). org.lz4:lz4-java:1.8.1 contains a redirect, but the latest version needs new coordinates. Modification: Update to latest version, with the forked group ID. Result: No more CVE-2025-12183. Co-authored-by: Jonas Konrad <jonas.konrad@oracle.com>
netty#15952) …re (netty#15949) Motivation: Connect is an outbound operation and so should onyl fail the promise. Modifications: - Don'T call fireExceptionCaught(...) - Add unit test Result: Correct exception reporting for connect failures
netty#15957) …… (netty#15954) …e DomainSocketAddress via LinuxSocket Motivation: We did not correctly handle abstract namespaces with UDS on linux when creating the DomainSocketAddress Modification: Correctly detect and handle abstract namespaces on linux Result: Correct code
…15965) Motivation: DefaultSctpServerChannelConfig did miss to respect SO_BACKLOG which is not expected Modifications: Correctly handle SO_BACKLOG Result: Correctly handle all ChannelOptions for SctpServerChannelConfig
…netty#15962) Motivation: HttpServerCodec always constructs an `EmptyLastHttpContent` and passes it to the Handler chain when processing OPTIONS requests, The `EmptyLastHttpContent` propagate through the handler chain. However, the CORS handler might still propagate the EmptyLastHttpContent to downstream handlers via fireChannelRead(), causing subsequent handlers to receive only this empty content and lose access to the original request URL. Because `CorsHandler` does not consume this message, it calls `ctx.fireChannelRead(msg)` for the EmptyLastHttpContent. Downstream handlers then observe: No HttpRequest A LastHttpContent with empty content This often breaks other handlers that rely on receiving the `HttpRequest` first or expect consistent HTTP message. This PR fixes an issue in `CorsHandler` where, after handling a CORS preflight (OPTIONS) request, the handler still propagates the subsequent `EmptyLastHttpContent` sent by the `HttpServerCodec` to downstream handler. Modification: - `CorsHandler` track handled preflight and consume the following HttpContent, LastHttpContent until the next HttpRequest is forwarded instead of firing it downstream. - Add tests Result: Fixes netty#15148 It also improves compatibility with application frameworks and routing handlers that expect well-formed HTTP request/response flows. Signed-off-by: skyguard1 <qhdxssm@qq.com> Co-authored-by: skyguard1 <qhdxssm@qq.com> Co-authored-by: xingrufei <xingrufei@yl.com> Co-authored-by: code-xing_wcar <code.xing@wirelesscar.com>
netty#15970) …… (netty#15896) …an error Motivation: We should close the Channel and fail the future of the bootstrap if during setting a ChannelOption we observe an error. At the moment we just log which might make things hard to debug and leave the Channel in an unexpected state. People can go back to the old behavior by using `-Dio.netty.bootstrap.closeOnSetOptionFailure=false`. Modifications: - Adjust code to also close and faile the future - Add testcases Result: Related to netty#15860 (comment)
Motivation: If initializeIfNecessary(...) fails we still need to ensure that we release the message. Modifications: Correctly release message before rethrow or fail promise Result: Fix possible buffer leak
) (netty#15983) Motivation: We used some odd number for the length, just use the exact length that we need. Modifications: - Allocate a byte[] of 25 length and remove odd comment Result: Cleanup
New vulnerability: [CVE-2025-66566](GHSA-cmp6-m4wj-q63q) Co-authored-by: Jonas Konrad <jonas.konrad@oracle.com>
tiagomlalves
force-pushed
the
dse-netty-4.1.132
branch
16 times, most recently
from
a955118 to
5fa8d65
Compare
tiagomlalves
force-pushed
the
dse-netty-4.1.132
branch
from
5fa8d65 to
66ec744
Compare
tiagomlalves
force-pushed
the
dse-netty-4.1.132
branch
from
50664af to
df2e892
Compare
tiagomlalves
force-pushed
the
dse-netty-4.1.132
branch
from
df2e892 to
8bac3a7
Compare
tiagomlalves
force-pushed
the
dse-netty-4.1.132
branch
from
3c11864 to
c5e78e8
Compare
tiagomlalves
force-pushed
the
dse-netty-4.1.132
branch
from
c5e78e8 to
f58448d
Compare
… not building linux arm and riscv which are required
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
12 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.