Netty

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Changed Http2ClientConnectionHandler to print out the aggregated buffers content

Motivation:

When running the Http2Client the data returned from the server, the

"Hello World" string, is supposed to be printed but instead the following

is displayed:

Received message:

Modifications:

Use the aggregated buffer to print out.

Result:

The example now logs the correct data sent from the server:

Received message: Hello World

Removing unused Http2PrefaceHandler.

Motivation:

All of the functionality has been merged into

AbstractHttp2ConnectionHandler.

Modifications:

Removed the Http2PrefaceHandler/Test and all uses.

Result:

Code cleaned up a bit.

Fix the cruft produced from the refactoring

.. in 330404da07859f5dc2e2263da719ad4161f17d99

Fix unclean backport in InternalLoggerFactory

.. which leaked in from d0912f27091e4548466df81f545c017a25c9d256

Fix most inspector warnings

Motivation:

It's good to minimize potentially broken windows.

Modifications:

Fix most inspector warnings from our profile

Update IntObjectHashMap

Result:

Cleaner code

  1. … 135 more files in changeset.
Fix most inspector warnings

Motivation:

It's good to minimize potentially broken windows.

Modifications:

Fix most inspector warnings from our profile

Result:

Cleaner code

  1. … 140 more files in changeset.
Fix most inspector warnings

Motivation:

It's good to minimize potentially broken windows.

Modifications:

Fix most inspector warnings from our profile

Update IntObjectHashMap

Result:

Cleaner code

  1. … 118 more files in changeset.
[#2618] Introduce ChannelPromise.unvoid() and ChannelFuture.isVoid()

Motivation:

There is no way for a ChannelHandler to check if the passed in ChannelPromise for a write(...) call is a VoidChannelPromise. This is a problem as some handlers need to add listeners to the ChannelPromise which is not possible in the case of a VoidChannelPromise.

Modification:

- Introduce ChannelFuture.isVoid() which will return true if it is not possible to add listeners or wait on the result.

- Add ChannelPromise.unvoid() which allows to create a ChannelFuture out of a void ChannelFuture which supports all the operations.

Result:

It's now easy to write ChannelHandler implementations which also works when a void ChannelPromise is used.

[#2618] Introduce ChannelPromise.unvoid() and ChannelFuture.isVoid()

Motivation:

There is no way for a ChannelHandler to check if the passed in ChannelPromise for a write(...) call is a VoidChannelPromise. This is a problem as some handlers need to add listeners to the ChannelPromise which is not possible in the case of a VoidChannelPromise.

Modification:

- Introduce ChannelFuture.isVoid() which will return true if it is not possible to add listeners or wait on the result.

- Add ChannelPromise.unvoid() which allows to create a ChannelFuture out of a void ChannelFuture which supports all the operations.

Result:

It's now easy to write ChannelHandler implementations which also works when a void ChannelPromise is used.

Clean up HTTP/2 integration tests

Related pull request: #2481 written by @nmittler

Motivation:

Some tests were still sending requests from the test thread rather than

from the event loop.

Modifications:

- Modified the roundtrip tests to use a new utility Http2TestUtil to

perform the write operations in the event loop thread.

- Modified the Http2Client under examples to write all requests in the

event loop thread.

- Added HttpPrefaceHandler and its test which were missing.

- Fixed various inspector warnings

Result:

Tests and examples now send requests in the correct thread context.

Fix inspector warnings

- Move the methods used by an inner class to the inner class

- Removal of various redundant things (throws, parens, ..)

[#2558] Define SO_REUSEPORT if not defined

Motivation:

Currently it is impossible to build netty on linux system that not define SO_REUSEPORT even if it is supported.

Modification:

Define SO_REUSEPORT if not defined.

Result:

Possible to build on more linux dists.

    • -0
    • +6
    /transport-native-epoll/src/main/c/io_netty_channel_epoll_Native.h
[#2558] Define SO_REUSEPORT if not defined

Motivation:

Currently it is impossible to build netty on linux system that not define SO_REUSEPORT even if it is supported.

Modification:

Define SO_REUSEPORT if not defined.

Result:

Possible to build on more linux dists.

    • -0
    • +6
    /transport-native-epoll/src/main/c/io_netty_channel_epoll_Native.h
[#2558] Define SO_REUSEPORT if not defined

Motivation:

Currently it is impossible to build netty on linux system that not define SO_REUSEPORT even if it is supported.

Modification:

Define SO_REUSEPORT if not defined.

Result:

Possible to build on more linux dists.

    • -0
    • +6
    /transport-native-epoll/src/main/c/io_netty_channel_epoll_Native.h
Correctly return from selector loop one a scheduled task is ready for processing

Motivation:

We use the nanoTime of the scheduledTasks to calculate the milli-seconds to wait for a select operation to select something. Once these elapsed we check if there was something selected or some task is ready for processing. Unfortunally we not take into account scheduled tasks here so the selection loop will continue if only scheduled tasks are ready for processing. This will delay the execution of these tasks.

Modification:

- Check if a scheduled task is ready after selecting

- also make a tiny change in NioEventLoop to not trigger a rebuild if nothing was selected because the timeout was reached a few times in a row.

Result:

Execute scheduled tasks on time.

Correctly return from selector loop one a scheduled task is ready for processing

Motivation:

We use the nanoTime of the scheduledTasks to calculate the milli-seconds to wait for a select operation to select something. Once these elapsed we check if there was something selected or some task is ready for processing. Unfortunally we not take into account scheduled tasks here so the selection loop will continue if only scheduled tasks are ready for processing. This will delay the execution of these tasks.

Modification:

- Check if a scheduled task is ready after selecting

- also make a tiny change in NioEventLoop to not trigger a rebuild if nothing was selected because the timeout was reached a few times in a row.

Result:

Execute scheduled tasks on time.

Correctly return from selector loop one a scheduled task is ready for processing

Motivation:

We use the nanoTime of the scheduledTasks to calculate the milli-seconds to wait for a select operation to select something. Once these elapsed we check if there was something selected or some task is ready for processing. Unfortunally we not take into account scheduled tasks here so the selection loop will continue if only scheduled tasks are ready for processing. This will delay the execution of these tasks.

Modification:

- Check if a scheduled task is ready after selecting

- also make a tiny change in NioEventLoop to not trigger a rebuild if nothing was selected because the timeout was reached a few times in a row.

Result:

Execute scheduled tasks on time.

Update dependency from org.jboss.logging:jboss-logging-spi:2.1.2.GA to org.jboss.logging:jboss-logging:3.1.4.GA

Update dependency from org.jboss.logging:jboss-logging-spi:2.1.2.GA to org.jboss.logging:jboss-logging:3.1.4.GA

Update dependency from org.jboss.logging:jboss-logging-spi:2.1.2.GA to org.jboss.logging:jboss-logging:3.1.4.GA

Update dependency from org.jboss.logging:jboss-logging-spi:2.1.2.GA to org.jboss.logging:jboss-logging:3.1.4.GA

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

[maven-release-plugin] prepare release netty-4.0.21.Final

[#2623] Release local references to guard against StackOverflow in JNI

Motivation:

When we do a (env*)->GetObjectArrayElement(...) call we may created many local references which will only be cleaned up once we exist the native method. Thus a lot of memory can be used and so a StackOverFlow may be triggered. Beside this the JNI specification only say that an implementation must cope with 16 local references.

Modification:

Call (env*)->ReleaseLocalRef(...) to release the resource once not needed anymore.

Result:

Less memory usage and guard against StackOverflow

    • -0
    • +12
    /transport-native-epoll/src/main/c/io_netty_channel_epoll_Native.c
[#2623] Release local references to guard against StackOverflow in JNI

Motivation:

When we do a (env*)->GetObjectArrayElement(...) call we may created many local references which will only be cleaned up once we exist the native method. Thus a lot of memory can be used and so a StackOverFlow may be triggered. Beside this the JNI specification only say that an implementation must cope with 16 local references.

Modification:

Call (env*)->ReleaseLocalRef(...) to release the resource once not needed anymore.

Result:

Less memory usage and guard against StackOverflow

    • -0
    • +17
    /transport-native-epoll/src/main/c/io_netty_channel_epoll_Native.c
[#2623] Release local references to guard against StackOverflow in JNI

Motivation:

When we do a (env*)->GetObjectArrayElement(...) call we may created many local references which will only be cleaned up once we exist the native method. Thus a lot of memory can be used and so a StackOverFlow may be triggered. Beside this the JNI specification only say that an implementation must cope with 16 local references.

Modification:

Call (env*)->ReleaseLocalRef(...) to release the resource once not needed anymore.

Result:

Less memory usage and guard against StackOverflow

    • -0
    • +17
    /transport-native-epoll/src/main/c/io_netty_channel_epoll_Native.c
[#2622] Correctly check reference count before try to work on the underlying memory

Motivation:

Because of how we use reference counting we need to check for the reference count before each operation that touches the underlying memory. This is especially true as we use sun.misc.Cleaner.clean() to release the memory ASAP when possible. Because of this the user may cause a SEGFAULT if an operation is called that tries to access the backing memory after it was released.

Modification:

Correctly check the reference count on all methods that access the underlying memory or expose it via a ByteBuffer.

Result:

Safer usage of ByteBuf

[#2622] Correctly check reference count before try to work on the underlying memory

Motivation:

Because of how we use reference counting we need to check for the reference count before each operation that touches the underlying memory. This is especially true as we use sun.misc.Cleaner.clean() to release the memory ASAP when possible. Because of this the user may cause a SEGFAULT if an operation is called that tries to access the backing memory after it was released.

Modification:

Correctly check the reference count on all methods that access the underlying memory or expose it via a ByteBuffer.

Result:

Safer usage of ByteBuf

[#2622] Correctly check reference count before try to work on the underlying memory

Motivation:

Because of how we use reference counting we need to check for the reference count before each operation that touches the underlying memory. This is especially true as we use sun.misc.Cleaner.clean() to release the memory ASAP when possible. Because of this the user may cause a SEGFAULT if an operation is called that tries to access the backing memory after it was released.

Modification:

Correctly check the reference count on all methods that access the underlying memory or expose it via a ByteBuffer.

Result:

Safer usage of ByteBuf

Fix compile error