Netty

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Add logging configuration to pom.xml

Motivation:

Currently the default log level when running tests is debug. When

running the build on the CI server it might be nice to avoid this debug

level and allow for the level to be configured.

Modifications:

Added a logback-test.xml configuration that has been added to the

common module. This allows for the logLevel to be configured.

The default level will still be debug.

Result:

The log level can now be configured from the command line:

$ mvn test -DlogLevel=error

    • -0
    • +11
    /common/src/test/resources/logback-test.xml
Add logging configuration to pom.xml

Motivation:

Currently the default log level when running tests is debug. When

running the build on the CI server it might be nice to avoid this debug

level and allow for the level to be configured.

Modifications:

Added a logback-test.xml configuration that has been added to the

common module. This allows for the logLevel to be configured.

The default level will still be debug.

Result:

The log level can now be configured from the command line:

$ mvn test -DlogLevel=error

    • -0
    • +11
    /common/src/test/resources/logback-test.xml
Support preloading of tcnative share lib

Motivation:

Some applications may use alternative methods of loading the tcnative JNI symbols. We should support this use case.

Modifications:

Separate the loading and initialzation of the tcnative library so that each can fail independently.

Result:

Fixes #5043

Support preloading of tcnative share lib

Motivation:

Some applications may use alternative methods of loading the tcnative JNI symbols. We should support this use case.

Modifications:

Separate the loading and initialzation of the tcnative library so that each can fail independently.

Result:

Fixes #5043

Fix IndexOutOfBoundsException when FixedCompositeByteBuf is constructed with an empty array.

Motivation:

When FixedCompositeByteBuf was constructed with new ByteBuf[0] and IndexOutOfboundsException was thrown.

Modifications:

Fix constructor

Result:

No more exception

Fix IndexOutOfBoundsException when FixedCompositeByteBuf is constructed with an empty array.

Motivation:

When FixedCompositeByteBuf was constructed with new ByteBuf[0] and IndexOutOfboundsException was thrown.

Modifications:

Fix constructor

Result:

No more exception

Add CharSequence operations to ByteBuf

Motivation:

Often users either need to read or write CharSequences to a ByteBuf. We should add methods for this to ByteBuf as we can do some optimizations for this depending on the implementation.

Modifications:

Add setCharSequence, writeCharSequence, getCharSequence and readCharSequence

Result:

Easier reading / writing of CharSequence with ByteBuf.

[#4635] Stop decoding if decoder was removed in ReplayingDecoder

We need to check if this handler was removed before continuing with decoding.

If it was removed, it is not safe to continue to operate on the buffer. This was already fixed for ByteToMessageDecoder in 4cdbe3928424b5b38695967c0cc1062dccf1a83c but missed for ReplayingDecoder.

Modifications:

Check if decoder was removed after fire messages through the pipeline.

Result:

No illegal buffer access when decoder was removed.

[#4635] Stop decoding if decoder was removed in ReplayingDecoder

We need to check if this handler was removed before continuing with decoding.

If it was removed, it is not safe to continue to operate on the buffer. This was already fixed for ByteToMessageDecoder in 4cdbe3928424b5b38695967c0cc1062dccf1a83c but missed for ReplayingDecoder.

Modifications:

Check if decoder was removed after fire messages through the pipeline.

Result:

No illegal buffer access when decoder was removed.

Correctly handle ChannelInputShutdownEvent in ReplayingDecoder

Motivation:

b112673554bafc1eccfd43913a3e8605337dd7fb added ChannelInputShutdownEvent support to ByteToMessageDecoder but missed updating the code for ReplayingDecoder. This has the effect:

- If a ChannelInputShutdownEvent is fired ByteToMessageDecoder (the super-class of ReplayingDecoder) will call the channelInputClosed(...) method which will pass the incorrect buffer to the decode method of ReplayingDecoder.

Modifications:

Share more code between ByteToMessageDEcoder and ReplayingDecoder and so also support ChannelInputShutdownEvent correctly in ReplayingDecoder

Result:

ChannelInputShutdownEvent is corrrectly handle in ReplayingDecoder as well.

Correctly handle ChannelInputShutdownEvent in ReplayingDecoder

Motivation:

b112673554bafc1eccfd43913a3e8605337dd7fb added ChannelInputShutdownEvent support to ByteToMessageDecoder but missed updating the code for ReplayingDecoder. This has the effect:

- If a ChannelInputShutdownEvent is fired ByteToMessageDecoder (the super-class of ReplayingDecoder) will call the channelInputClosed(...) method which will pass the incorrect buffer to the decode method of ReplayingDecoder.

Modifications:

Share more code between ByteToMessageDEcoder and ReplayingDecoder and so also support ChannelInputShutdownEvent correctly in ReplayingDecoder

Result:

ChannelInputShutdownEvent is corrrectly handle in ReplayingDecoder as well.

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

  1. … 14 more files in changeset.
[maven-release-plugin] prepare release netty-4.1.0.CR7

  1. … 14 more files in changeset.
Fix resource leak in test introduced by 69070c37baf55e181f9270270f7cbf25958ba9b3

Fix resource leak in test introduced by 69070c37baf55e181f9270270f7cbf25958ba9b3

We need to ensure we correct reset decoder in decodeLast() to not produce multiple LastHttpContent instances.

Motivation:

We missed to reset the decoder when asked for it in HttpObjectDecoder and so sometimes could produce more then one LastHttpContent in a sequence during channelInactive.

This did show up as AssertionError:

22:22:35.499 [nioEventLoopGroup-3-1] WARN i.n.channel.DefaultChannelPipeline - An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception.

java.lang.AssertionError: null

at io.netty.handler.codec.http.HttpObjectAggregator.decode(HttpObjectAggregator.java:205) ~[classes/:na]

at io.netty.handler.codec.http.HttpObjectAggregator.decode(HttpObjectAggregator.java:57) ~[classes/:na]

at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:89) ~[classes/:na]

at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292) [classes/:na]

at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278) [classes/:na]

at io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.fireChannelRead(CombinedChannelDuplexHandler.java:428) [classes/:na]

at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:277) [classes/:na]

at io.netty.handler.codec.ByteToMessageDecoder.channelInputClosed(ByteToMessageDecoder.java:343) [classes/:na]

at io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:309) [classes/:na]

at io.netty.handler.codec.http.HttpClientCodec$Decoder.channelInactive(HttpClientCodec.java:228) [classes/:na]

at io.netty.channel.CombinedChannelDuplexHandler.channelInactive(CombinedChannelDuplexHandler.java:213) [classes/:na]

...

Modifications:

Correctly reset decoder.

Result:

Correctly only produce one LastHttpContent per sequence.

We need to ensure we correct reset decoder in decodeLast() to not produce multiple LastHttpContent instances.

Motivation:

We missed to reset the decoder when asked for it in HttpObjectDecoder and so sometimes could produce more then one LastHttpContent in a sequence during channelInactive.

This did show up as AssertionError:

22:22:35.499 [nioEventLoopGroup-3-1] WARN i.n.channel.DefaultChannelPipeline - An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception.

java.lang.AssertionError: null

at io.netty.handler.codec.http.HttpObjectAggregator.decode(HttpObjectAggregator.java:205) ~[classes/:na]

at io.netty.handler.codec.http.HttpObjectAggregator.decode(HttpObjectAggregator.java:57) ~[classes/:na]

at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:89) ~[classes/:na]

at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:292) [classes/:na]

at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:278) [classes/:na]

at io.netty.channel.CombinedChannelDuplexHandler$DelegatingChannelHandlerContext.fireChannelRead(CombinedChannelDuplexHandler.java:428) [classes/:na]

at io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:277) [classes/:na]

at io.netty.handler.codec.ByteToMessageDecoder.channelInputClosed(ByteToMessageDecoder.java:343) [classes/:na]

at io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:309) [classes/:na]

at io.netty.handler.codec.http.HttpClientCodec$Decoder.channelInactive(HttpClientCodec.java:228) [classes/:na]

at io.netty.channel.CombinedChannelDuplexHandler.channelInactive(CombinedChannelDuplexHandler.java:213) [classes/:na]

...

Modifications:

Correctly reset decoder.

Result:

Correctly only produce one LastHttpContent per sequence.

[maven-release-plugin] rollback the release of netty-4.1.0.CR7

  1. … 14 more files in changeset.
[maven-release-plugin] prepare release netty-4.1.0.CR7

  1. … 14 more files in changeset.
[#5104] Fix possible deadlock in DefaultChannelPipeline

Motivation:

When a user has multiple EventLoops in an EventLoopGroup and calls pipeline.add* / remove* / replace from an EventLoop that belongs to another Channel it is possible to deadlock if the other EventLoop does the same.

Modification:

- Only ensure the actual modification takes place in a synchronized block and not wait until the handlerAdded(...) / handlerRemoved(...) method is called. This is ok as we submit the task to the executor while still holding the look and so ensure correct order of pipeline modifications.

- Ensure if an AbstractChannelHandlerContext is put in the linked-list structure but the handlerAdded(...) method was not called we skip it until handlerAdded(...) was called. This is needed to ensure handlerAdded(...) is always called first.

Result:

Its not possible to deadlock when modify the DefaultChannelPipeline.

[#5104] Fix possible deadlock in DefaultChannelPipeline

Motivation:

When a user has multiple EventLoops in an EventLoopGroup and calls pipeline.add* / remove* / replace from an EventLoop that belongs to another Channel it is possible to deadlock if the other EventLoop does the same.

Modification:

- Only ensure the actual modification takes place in a synchronized block and not wait until the handlerAdded(...) / handlerRemoved(...) method is called. This is ok as we submit the task to the executor while still holding the look and so ensure correct order of pipeline modifications.

- Ensure if an AbstractChannelHandlerContext is put in the linked-list structure but the handlerAdded(...) method was not called we skip it until handlerAdded(...) was called. This is needed to ensure handlerAdded(...) is always called first.

Result:

Its not possible to deadlock when modify the DefaultChannelPipeline.

Revert "[#5028] Fix re-entrance issue with channelWritabilityChanged(...) and write(...)"

Motivation:

Revert 2e68e370253d06e78e3970b7be77216d6f1f6b85. Delaying the notification of writability change may lead to notification being missed. This is a ABA type of concurrency problem.

Modifications:

Revert 2e68e370253d06e78e3970b7be77216d6f1f6b85.

Result:

channelWritabilityChange will be called on every change, and will not be suppressed due to ABA scenario.

Revert "[#5028] Fix re-entrance issue with channelWritabilityChanged(...) and write(...)"

Motivation:

Revert d0943dcd30b08eb4043aeb88fd983bcebf8c3432. Delaying the notification of writability change may lead to notification being missed. This is a ABA type of concurrency problem.

Modifications:

- Revert d0943dcd30b08eb4043aeb88fd983bcebf8c3432.

Result:

channelWritabilityChange will be called on every change, and will not be suppressed due to ABA scenario.

Fix potential assertion error introduced by 0bc93dd

Motivation:

Commit 0bc93dd introduced a potential assertion failure, if the deprecated method would be used.

Modifications:

Fix the potential assertion error.

Result:

Regression removed

Cleanup PoolChunk and PoolArena

Motivation:

To make it easier to understand PoolChunk and PoolArena we should cleanup duplicated code.

Modifications:

- Move reused code into methods

- Use Math.max(...)

Result:

Cleaner code and easier to understand.

Cleanup PoolChunk and PoolArena

Motivation:

To make it easier to understand PoolChunk and PoolArena we should cleanup duplicated code.

Modifications:

- Move reused code into methods

- Use Math.max(...)

Result:

Cleaner code and easier to understand.

Fix checkstyle

Fix an assertion error introduced by 0bc93dda081499dfe4f96a1507d24fa46bf0f31f

Motivation:

    

Commit 0bc93dda081499dfe4f96a1507d24fa46bf0f31f introduced an assertion

failure.

Modifications:

Fix the assertion error.

Result:

Regression removed

NIO autoReadClear should also clear the SelectionKey

Motivation:

Prior to 5b48fc284ebe85ca4974985e3be005d37626e980 setting readPending to false when autoReadClear was called was enough because when/if the EventLoop woke up with a read event we would first check if readPending was true and if it is not, we would return early. Now that readPending will only be set in the EventLoop it is not necessary to check readPending at the start of the read methods, and we should instead remove the OP_READ from the SelectionKey when we also set readPending to false.

Modifications:

- autoReadCleared should call AbstractNioUnsafe.removeReadOp

Result:

NIO is now consistent with EPOLL and removes the READ operation on the selector when autoRead is cleared.

EPOLL ET Set ReadFlag and Limit epollInReadyRunnable

Motivation:

441aa4c5756b975e8ee1dccbe2902633e0f587e8 conditionally set the readFlag based upon if maybeMoreDataToRead is set. It is possible that the read flag will not be set, and nothing will be read by executeEpollInReadyRunnable and no actual data will be read even though the user requested it.

Modifications:

- Always set the readFlag in doBeginRead

- Make it so only a single epollInReadyRunnable can execute for a channel at a time

Result:

Less chance of missing read events in EPOLL transport.