Netty

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Replace accumulation with blackhole.consume (#9275)

Motivation:

SpotJMHBugs reports that accumulating a value as a way of eliding dead code

elimination may be inadvisable, as discussed in

`JMHSample_34_SafeLooping::measureWrong_2`. Change the test so that it consumes

the response with `Blackhole::consume` instead.

Modifications:

- Replace addition of results with explicit `blackhole.consume()` call

Result:

Tests work as before, but with different benchmark numbers.

Replace accumulation with blackhole.consume (#9275)

Motivation:

SpotJMHBugs reports that accumulating a value as a way of eliding dead code

elimination may be inadvisable, as discussed in

`JMHSample_34_SafeLooping::measureWrong_2`. Change the test so that it consumes

the response with `Blackhole::consume` instead.

Modifications:

- Replace addition of results with explicit `blackhole.consume()` call

Result:

Tests work as before, but with different benchmark numbers.

Documented non-usage of BlackHole::consume on ByteBufAccessBenchmark (#9279)

Motivation:

Some JMH benchmarks need additional explanations to motivate

specific code choices.

Modifications:

Introduced comment to explai why calling BlackHole::consume

in a loop is not always the right choice for some benchmark.

Result:

The relevant method shows a comment that warn about changing

the code to introduce BlackHole::consume in the loop.

Documented non-usage of BlackHole::consume on ByteBufAccessBenchmark (#9279)

Motivation:

Some JMH benchmarks need additional explanations to motivate

specific code choices.

Modifications:

Introduced comment to explai why calling BlackHole::consume

in a loop is not always the right choice for some benchmark.

Result:

The relevant method shows a comment that warn about changing

the code to introduce BlackHole::consume in the loop.

Add null check to isSkippable. Fixes #9278 (#9280)

Motivation:

Currently GraalVM substrate returns null for reflective calls if the reflection access is not declared up front.

A change introduced in Netty 4.1.35 results in needing to register every Netty handler for reflection. This complicates matters as it is difficult to know all the possible handlers that need to be registered.

Modification:

This change adds a simple

null check such that Netty does not break on GraalVM substrate without the reflection information registration.

Result:

Fixes #9278

Add null check to isSkippable. Fixes #9278 (#9280)

Motivation:

Currently GraalVM substrate returns null for reflective calls if the reflection access is not declared up front.

A change introduced in Netty 4.1.35 results in needing to register every Netty handler for reflection. This complicates matters as it is difficult to know all the possible handlers that need to be registered.

Modification:

This change adds a simple

null check such that Netty does not break on GraalVM substrate without the reflection information registration.

Result:

Fixes #9278

Limit the amount of pending streams to process by 100 before trying to store more to reduce risk of memory overhead

Don't filter out TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (#9274)

Motivation:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 is supported since Java 8 (see https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html) and belongs to the recommended configurations in many references, eg SSLabs (https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices) or Google Cloud Platform Restricted Profile.

Modifications:

Add TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 to default ciphers list.

Result:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 is enabled by default.

Don't filter out TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (#9274)

Motivation:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 is supported since Java 8 (see https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html) and belongs to the recommended configurations in many references, eg SSLabs (https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices) or Google Cloud Platform Restricted Profile.

Modifications:

Add TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 to default ciphers list.

Result:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 is enabled by default.

EmptyByteBuf.getCharSequence(0,...) must return empty String (#9272)

Motivation:

At the moment EmptyByteBuf.getCharSequence(0,...) will return null while it must return a "".

Modifications:

- Let EmptyByteBuf.getCharSequence(0,...) return ""

- Add unit test

Result:

Fixes https://github.com/netty/netty/issues/9271.

EmptyByteBuf.getCharSequence(0,...) must return empty String (#9272)

Motivation:

At the moment EmptyByteBuf.getCharSequence(0,...) will return null while it must return a "".

Modifications:

- Let EmptyByteBuf.getCharSequence(0,...) return ""

- Add unit test

Result:

Fixes https://github.com/netty/netty/issues/9271.

Cleanup http2 example code to make clear it is fine to just use ctx directly. (#9276)

Motivation:

In our example we did use pipeline.context(this) to obtain the context of the handler while it was already passed in via ctx. This could confuse users and give the impression that the context is no the same.

Modifications:

Just use ctx directly.

Result:

Fix confusion in example code. This was brought up on stackoverflow:

https://stackoverflow.com/questions/56711128/when-is-a-channelhandlercontext-handed-to-a-channelhandler-not-that-channelhandl

Cleanup http2 example code to make clear it is fine to just use ctx directly. (#9276)

Motivation:

In our example we did use pipeline.context(this) to obtain the context of the handler while it was already passed in via ctx. This could confuse users and give the impression that the context is no the same.

Modifications:

Just use ctx directly.

Result:

Fix confusion in example code. This was brought up on stackoverflow:

https://stackoverflow.com/questions/56711128/when-is-a-channelhandlercontext-handed-to-a-channelhandler-not-that-channelhandl

Cleanup http2 example code to make clear it is fine to just use ctx directly.

Motivation:

In our example we did use pipeline.context(this) to obtain the context of the handler while it was already passed in via ctx. This could confuse users and give the impression that the context is no the same.

Modifications:

Just use ctx directly.

Result:

Fix confusion in example code. This was brought up on stackoverflow:

https://stackoverflow.com/questions/56711128/when-is-a-channelhandlercontext-handed-to-a-channelhandler-not-that-channelhandl

Don't filter out TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

Motivation:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 is supported since Java 8 (see https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html) and belongs to the recommended configurations in many references, eg SSLabs (https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices) or Google Cloud Platform Restricted Profile.

Modifications:

Add TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 to default ciphers list.

Result:

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 is enabled by default.

Reduce coupling between Http2FrameCodec and Http2Multiplex*

Motivation:

Http2MultiplexCodec and Http2MultiplexHandler had a very strong coupling with Http2FrameCodec which we can reduce easily. The end-goal should be to have no coupling at all.

Modifications:

- Reduce coupling by move some common logic to Http2CodecUtil

- Move logic to check if a stream may have existed before to Http2FrameCodec

- Use ArrayDeque as replacement for custom double-linked-list which makes the code a lot more readable

- Use WindowUpdateFrame to signal consume bytes (just as users do when they use Http2FrameCodec directly)

Result:

Less coupling and cleaner code.

Reduce coupeling between Http2FrameCodec and Http2Multiplex*

Motivation:

Http2MultiplexCodec and Http2MultiplexHandler had a very strong coupeling with Http2FrameCodec which we can reduce easily. The end-goal should be to have no cupeling at all.

Modifications:

- Reduce cupeling by move some common logic to Http2CodecUtil

- Move logic to check if a stream may have existed before to Http2FrameCodec

- Use ArrayDeque as replacement for custom double-linked-list which makes the code a lot more readable

- Use WindowUpdateFrame to signal consume bytes (just as users do when they use Http2FrameCodec directly)

Result:

Less coupleing and cleaner code.

Preserve the original filename when encoding a multipart/form in mixed mode. (#9270)

Motivation:

The HttpPostRequestEncoder overwrites the original filename of file uploads sharing the same name encoded in mixed mode when it rewrites the multipart body header of the previous file. The original filename should be preserved instead.

Modifications:

Change the HttpPostRequestEncoder to reuse the correct filename when the encoder switches to mixed mode. The original test is incorrect and has been modified too, in addition it tests with an extra file upload since the current test was not testing the continuation of a mixed mode.

Result:

The HttpPostRequestEncoder will preserve the original filename of the first fileupload when switching to mixed mode

    • -0
    • +1
    /codec-http/src/test/resources/file-03.txt
Preserve the original filename when encoding a multipart/form in mixed mode. (#9270)

Motivation:

The HttpPostRequestEncoder overwrites the original filename of file uploads sharing the same name encoded in mixed mode when it rewrites the multipart body header of the previous file. The original filename should be preserved instead.

Modifications:

Change the HttpPostRequestEncoder to reuse the correct filename when the encoder switches to mixed mode. The original test is incorrect and has been modified too, in addition it tests with an extra file upload since the current test was not testing the continuation of a mixed mode.

Result:

The HttpPostRequestEncoder will preserve the original filename of the first fileupload when switching to mixed mode

    • -0
    • +1
    /codec-http/src/test/resources/file-03.txt
Fixed the haproxy message mem leak issue (#9250)

Motivation:

HAProxyMessage should be released as it contains a list of TLV which hold a ByteBuf, otherwise, it may cause memory leaks.

Modification:

- Let HAProxyMessage extend AbstractReferenceCounted

- Adjust tests.

Result:

Fixes #9201

Fixed the haproxy message mem leak issue (#9250)

Motivation:

HAProxyMessage should be released as it contains a list of TLV which hold a ByteBuf, otherwise, it may cause memory leaks.

Modification:

- Let HAProxyMessage extend AbstractReferenceCounted

- Adjust tests.

Result:

Fixes #9201

EmptyByteBuf.getCharSequence(0,...) must return empty String

Motivation:

At the moment EmptyByteBuf.getCharSequence(0,...) will return null while it must return a "".

Modifications:

- Let EmptyByteBuf.getCharSequence(0,...) return ""

- Add unit test

Result:

Fixes https://github.com/netty/netty/issues/9271.

Split multiplexing from frame decoding to allow easier customization of frame processing and better seperation of responsibilities (#9239)

Motivation:

In the past we had the following class hierarchy:

Http2ConnectionHandler --- Http2FrameCodec -- Http2MultiplexCodec

This hierarchy makes it impossible to plug in any code that would like to act on Http2Frame and Http2StreamFrame which can be quite useful for various situations (like metrics, logging etc). Beside this it also made the implementtion very hacky. To allow easier maintainance and also allow more flexible costumizations we should split Http2MultiplexCodec and Http2FrameCode.

Modifications:

- Introduce Http2MultiplexHandler (which is a replacement for Http2MultiplexCodec when used together with Http2FrameCodec)

- Mark Http2MultiplexCodecBuilder and Http2MultiplexCodec as deprecated. People should use Http2FrameCodecBuilder / Http2FrameCodec together with Http2MultiplexHandlder in the future

- Adjust / Add tests

- Adjust examples

Result:

More flexible usage possible and less hacky / coupled implementation for http2 multiplexing

  1. … 3 more files in changeset.
Split multiplexing from frame decoding to allow easier customization of frame processing and better seperation of responsibilities (#9239)

Motivation:

In the past we had the following class hierarchy:

Http2ConnectionHandler --- Http2FrameCodec -- Http2MultiplexCodec

This hierarchy makes it impossible to plug in any code that would like to act on Http2Frame and Http2StreamFrame which can be quite useful for various situations (like metrics, logging etc). Beside this it also made the implementtion very hacky. To allow easier maintainance and also allow more flexible costumizations we should split Http2MultiplexCodec and Http2FrameCode.

Modifications:

- Introduce Http2MultiplexHandler (which is a replacement for Http2MultiplexCodec when used together with Http2FrameCodec)

- Mark Http2MultiplexCodecBuilder and Http2MultiplexCodec as deprecated. People should use Http2FrameCodecBuilder / Http2FrameCodec together with Http2MultiplexHandlder in the future

- Adjust / Add tests

- Adjust examples

Result:

More flexible usage possible and less hacky / coupled implementation for http2 multiplexing

  1. … 3 more files in changeset.
Bugfix #9257: WebSocketProtocolHandler does NOT support autoRead=false (#9258)

Motivation:

I need to control WebSockets inbound flow manually, when autoRead=false

Modification:

Add missed ctx.read() call into WebSocketProtocolHandler, where read request has been swallowed.

Result:

Fixes #9257

Bugfix #9257: WebSocketProtocolHandler does NOT support autoRead=false (#9258)

Motivation:

I need to control WebSockets inbound flow manually, when autoRead=false

Modification:

Add missed ctx.read() call into WebSocketProtocolHandler, where read request has been swallowed.

Result:

Fixes #9257

Make EventLoopTaskQueueFactory a top-level interface

Motivation:

c9aaa93d83b5b571dbc733d2632232db82b3d884 added the ability to specify an EventLoopTaskQueueFactory but did place it under MultithreadEventLoopGroup while not really belongs there.

Modifications:

Make EventLoopTaskQueueFactory a top-level interface

Result:

More logical code layout.

Recycle RecyclableArrayDeque as fast as possible in FlowControlHandler (#9263)

Motivation:

FlowControlHandler does use a recyclable ArrayDeque internally but only recycles it when the channel is closed. We should better recycle it once it is empty.

Modifications:

Recycle the deque as fast as possible

Result:

Less RecyclableArrayDeque instances.

Recycle RecyclableArrayDeque as fast as possible in FlowControlHandler (#9263)

Motivation:

FlowControlHandler does use a recyclable ArrayDeque internally but only recycles it when the channel is closed. We should better recycle it once it is empty.

Modifications:

Recycle the deque as fast as possible

Result:

Less RecyclableArrayDeque instances.

Return the result of the list.recycle() call (#9264)

Motivation:

Resolve the issue highlighted by SpotJMHBugs that the creation of the RecyclableArrayList may be elided by the JIT since the result isn't consumed or returned.

Modifications:

Return the result of `list.recycle()` so that the list isn't elided.

Result:

The JMH benchmark shows a change in performance indicating that the prior results of this may be unsound.