Netty

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Adding payload to the Http2Client example.

Modifications:

When trying out the Http2Client example I noticed that adding a request

payload would not cause a data frame to written. This seems to be

because writeHeaders completes the promise, and then the writeData

call ends up in FlowControlWriter.writeFrame, isDone is true and

the data released and the call aborted and returned.

Adding a new promise for the writeData method allows a data frame to be

written.

Result:

A body/payload can now be sent to the server. The example was updated to

simply echo the payload received back to the calling client.

Fix another buffer leaks in JsonObjectDecoderTest

Fix another buffer leaks in JsonObjectDecoderTest

Reduce the perceived time taken to retrieve initialSeedUniquifier

Motivation:

When system is in short of entrophy, the initialization of

ThreadLocalRandom can take at most 3 seconds. The initialization occurs

when ThreadLocalRandom.current() is invoked first time, which might be

much later than the moment when the application has started. If we

start the initialization of ThreadLocalRandom as early as possible, we

can reduce the perceived time taken for the retrieval.

Modification:

Begin the initialization of ThreadLocalRandom in InternalLoggerFactory,

potentially one of the firstly initialized class in a Netty application.

Make DefaultChannelId retrieve the current process ID before retrieving

the current machine ID, because retrieval of a machine ID is more likely

to use ThreadLocalRandom.current().

Use a dummy channel ID for EmbeddedChannel, which prevents many unit

tests from creating a ThreadLocalRandom instance.

Result:

We gain extra 100ms at minimum for initialSeedUniquifier generation. If

an application has its own initialization that takes long enough time

and generates good amount of entrophy, it is very likely that we will

gain a lot more.

Reduce the perceived time taken to retrieve initialSeedUniquifier

Motivation:

When system is in short of entrophy, the initialization of

ThreadLocalRandom can take at most 3 seconds. The initialization occurs

when ThreadLocalRandom.current() is invoked first time, which might be

much later than the moment when the application has started. If we

start the initialization of ThreadLocalRandom as early as possible, we

can reduce the perceived time taken for the retrieval.

Modification:

Begin the initialization of ThreadLocalRandom in InternalLoggerFactory,

potentially one of the firstly initialized class in a Netty application.

Make DefaultChannelId retrieve the current process ID before retrieving

the current machine ID, because retrieval of a machine ID is more likely

to use ThreadLocalRandom.current().

Use a dummy channel ID for EmbeddedChannel, which prevents many unit

tests from creating a ThreadLocalRandom instance.

Result:

We gain extra 100ms at minimum for initialSeedUniquifier generation. If

an application has its own initialization that takes long enough time

and generates good amount of entrophy, it is very likely that we will

gain a lot more.

Log the time taken for generating the initialSeedUniquifier

- Sometimes useful to know it how long it takes from the log, to make

sure it's not something else that is blocking.

Log the time taken for generating the initialSeedUniquifier

- Sometimes useful to know it how long it takes from the log, to make

sure it's not something else that is blocking.

Log the time taken for generating the initialSeedUniquifier

- Sometimes useful to know it how long it takes from the log, to make

sure it's not something else that is blocking.

Make JsonObjectDecoder discard everything after stream corruption

Motivation:

There's no way to recover from a corrupted JSON stream. The current

implementation will raise an infinite exception storm when a peer sends

a large corrupted stream.

Modification:

Discard everything once stream corruption is detected.

Result:

Fixes a buffer leak

Fixes exception storm

Make JsonObjectDecoder discard everything after stream corruption

Motivation:

There's no way to recover from a corrupted JSON stream. The current

implementation will raise an infinite exception storm when a peer sends

a large corrupted stream.

Modification:

Discard everything once stream corruption is detected.

Result:

Fixes a buffer leak

Fixes exception storm

[#2586] Use correct EventLoop to notify delayed bind failures

Motivation:

When a bind fails AbstractBootstrap will use the GlobalEventExecutor to notify the ChannelPromise. We should use the EventLoop of the Channel if possible.

Modification:

Use EventLoop of the Channel if possible to use the correct Thread to notify and so guaranteer the right order of events.

Result:

Use the correct EventLoop for notification

[#2586] Use correct EventLoop to notify delayed bind failures

Motivation:

When a bind fails AbstractBootstrap will use the GlobalEventExecutor to notify the ChannelPromise. We should use the EventLoop of the Channel if possible.

Modification:

Use EventLoop of the Channel if possible to use the correct Thread to notify and so guaranteer the right order of events.

Result:

Use the correct EventLoop for notification

[#2586] Use correct EventLoop to notify delayed bind failures

Motivation:

When a bind fails AbstractBootstrap will use the GlobalEventExecutor to notify the ChannelPromise. We should use the EventLoop of the Channel if possible.

Modification:

Use EventLoop of the Channel if possible to use the correct Thread to notify and so guaranteer the right order of events.

Result:

Use the correct EventLoop for notification

Fix an inspector warning in JsonObjectDecoder

Fix an inspector warning in JsonObjectDecoder

Fix a buffer leak in JsonObjectDecoderTest

Fix a buffer leak in JsonObjectDecoderTest

Let OkResponseHandler extend SimpleChannelInboundHandler

Motivation:

OkResponseHandler is the last handler in the pipeline of the HTTP CORS

example. It is responsible for releasing all messages it handled.

Modification:

Extend SimpleChannelInboundHandler instead of ChannelHandlerAdapter

Result:

Fixed a leak

Let OkResponseHandler extend SimpleChannelInboundHandler

Motivation:

OkResponseHandler is the last handler in the pipeline of the HTTP CORS

example. It is responsible for releasing all messages it handled.

Modification:

Extend SimpleChannelInboundHandler instead of

ChannelInboundHandlerAdapter

Result:

Fixed a leak

Let OkResponseHandler extend SimpleChannelInboundHandler

Motivation:

OkResponseHandler is the last handler in the pipeline of the HTTP CORS

example. It is responsible for releasing all messages it handled.

Modification:

Extend SimpleChannelInboundHandler instead of

ChannelInboundHandlerAdapter

Result:

Fixed a leak

Fix the build timeout when 'leak' profile is active

Motivation:

AbstractByteBufTest.testInternalBuffer() uses writeByte() operations to

populate the sample data. Usually, this isn't a problem, but it starts

to take a lot of time when the resource leak detection level gets

higher.

In our CI machine, testInternalBuffer() takes more than 30 minutes,

causing the build timeout when the 'leak' profile is active (paranoid

level resource detection.)

Modification:

Populate the sample data using ThreadLocalRandom.nextBytes() instead of

using millions of writeByte() operations.

Result:

Test runs much faster when leak detection level is high.

Fix the build timeout when 'leak' profile is active

Motivation:

AbstractByteBufTest.testInternalBuffer() uses writeByte() operations to

populate the sample data. Usually, this isn't a problem, but it starts

to take a lot of time when the resource leak detection level gets

higher.

In our CI machine, testInternalBuffer() takes more than 30 minutes,

causing the build timeout when the 'leak' profile is active (paranoid

level resource detection.)

Modification:

Populate the sample data using ThreadLocalRandom.nextBytes() instead of

using millions of writeByte() operations.

Result:

Test runs much faster when leak detection level is high.

Fix the build timeout when 'leak' profile is active

Motivation:

AbstractByteBufTest.testInternalBuffer() uses writeByte() operations to

populate the sample data. Usually, this isn't a problem, but it starts

to take a lot of time when the resource leak detection level gets

higher.

In our CI machine, testInternalBuffer() takes more than 30 minutes,

causing the build timeout when the 'leak' profile is active (paranoid

level resource detection.)

Modification:

Populate the sample data using ThreadLocalRandom.nextBytes() instead of

using millions of writeByte() operations.

Result:

Test runs much faster when leak detection level is high.

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.