Netty

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
CorsHandler should release HttpRequest after processing preflight/error.

Motivation:

Currently, when the CorsHandler processes a preflight request, or

respondes with an 403 Forbidden using the short-curcuit option, the

HttpRequest is not released which leads to a buffer leak.

Modifications:

Releasing the HttpRequest when done processing a preflight request or

responding with an 403.

Result:

Using the CorsHandler will not cause buffer leaks.

Increase the timeout of ChannelDeregistrationTest

Motivation:

When a thread-local random is used first time, it tries to get the

initial seed uniquifier from SecureRandom, and it sometimes takes time

for the system to have enough entropy.

In ChannelDeregistrationTest, the retrieval of the initial seed

uniquifier takes place lazily when a new channel is created, and it

blocks the channel creation for more than 2 seconds, resulting in test

timeouts.

Modifications:

Increase the timeout of the tests to 5 seconds, because the timeout of

the initial seed uniquifier retrieval is 3 seconds.

Result:

Less flakey tests

Disable SSLv3 to avoid POODLE vulnerability

Related: #3031

Motivation:

The only way to protect ourselves from POODLE vulnerability in Java for

now is to disable SSLv3.

- http://en.wikipedia.org/wiki/POODLE

- https://blogs.oracle.com/security/entry/information_about_ssl_poodle_vulnerability

Modifivation:

Disable SSLv3 in SslContext implementations

Result:

Prevent POODLE vulnerability when a user used SslContext with the

default configuration

Disable SSLv3 to avoid POODLE vulnerability

Related: #3031

Motivation:

The only way to protect ourselves from POODLE vulnerability in Java for

now is to disable SSLv3.

- http://en.wikipedia.org/wiki/POODLE

- https://blogs.oracle.com/security/entry/information_about_ssl_poodle_vulnerability

Modifivation:

Disable SSLv3 in SslContext implementations

Result:

Prevent POODLE vulnerability when a user used SslContext with the

default configuration

Disable SSLv3 to avoid POODLE vulnerability

Related: #3031

Motivation:

The only way to protect ourselves from POODLE vulnerability in Java for

now is to disable SSLv3.

- http://en.wikipedia.org/wiki/POODLE

- https://blogs.oracle.com/security/entry/information_about_ssl_poodle_vulnerability

Modifivation:

Disable SSLv3 in SslContext implementations

Result:

Prevent POODLE vulnerability when a user used SslContext with the

default configuration

HTTP/2 Stream ID unit tests

Motivation:

There should be a unit test for when the stream ID wraps around and is 'too large' or negative.

The lack of unit test masked an issue where this was not being throw.

Modifications:

Add a unit test to cover the case where creating a remote and local stream where stream id is 'too large'

Result:

Unit test scope increases.

Slight performance improvement to IntObjectHashMap.hashIndex()

Motivation:

Using a needless local copy of keys.length.

Modifications:

Using keys.length explicitly everywhere.

Result:

Slight performance improvement of hashIndex.

Slight performance improvement to IntObjectHashMap.hashIndex()

Motivation:

Using a needless local copy of keys.length.

Modifications:

Using keys.length explicitly everywhere.

Result:

Slight performance improvement of hashIndex.

Slight performance improvement to IntObjectHashMap.hashIndex()

Motivation:

Using a needless local copy of keys.length.

Modifications:

Using keys.length explicitly everywhere.

Result:

Slight performance improvement of hashIndex.

Optimize IntObjectHashMap handling of negative keys.

Motivation:

The hashIndex method currently uses a conditional to handle negative

keys. This could be done without a conditional to slightly improve

performance.

Modifications:

Modified hashIndex() to avoid using a conditional.

Result:

Slight performance improvement to hashIndex().

Optimize IntObjectHashMap handling of negative keys.

Motivation:

The hashIndex method currently uses a conditional to handle negative

keys. This could be done without a conditional to slightly improve

performance.

Modifications:

Modified hashIndex() to avoid using a conditional.

Result:

Slight performance improvement to hashIndex().

Optimize IntObjectHashMap handling of negative keys.

Motivation:

The hashIndex method currently uses a conditional to handle negative

keys. This could be done without a conditional to slightly improve

performance.

Modifications:

Modified hashIndex() to avoid using a conditional.

Result:

Slight performance improvement to hashIndex().

Allowing negative keys in IntObjectHashMap.

Motivation:

IntObjectHashMap throws an exception when using negative values for

keys.

Modifications:

Changed hashIndex() to normalize the index if the mod operation returns

a negative number.

Result:

IntObjectHashMap supports negative key values.

Allowing negative keys in IntObjectHashMap.

Motivation:

IntObjectHashMap throws an exception when using negative values for

keys.

Modifications:

Changed hashIndex() to normalize the index if the mod operation returns

a negative number.

Result:

IntObjectHashMap supports negative key values.

Allowing negative keys in IntObjectHashMap.

Motivation:

IntObjectHashMap throws an exception when using negative values for

keys.

Modifications:

Changed hashIndex() to normalize the index if the mod operation returns

a negative number.

Result:

IntObjectHashMap supports negative key values.

More complete OpenSslEngine SSLSession implementation

Motivation:

The current SSLSession implementation used by OpenSslEngine does not support various operations and so may not be a good replacement by the SSLEngine provided by the JDK implementation.

Modifications:

- Add SSLSession.getCreationTime()

- Add SSLSession.getLastAccessedTime()

- Add SSLSession.putValue(...), getValue(...), removeValue(...), getValueNames()

- Add correct SSLSession.getProtocol()

- Ensure OpenSSLEngine.getSession() is thread-safe

- Use optimized AtomicIntegerFieldUpdater when possible

Result:

More complete OpenSslEngine SSLSession implementation

More complete OpenSslEngine SSLSession implementation

Motivation:

The current SSLSession implementation used by OpenSslEngine does not support various operations and so may not be a good replacement by the SSLEngine provided by the JDK implementation.

Modifications:

- Add SSLSession.getCreationTime()

- Add SSLSession.getLastAccessedTime()

- Add SSLSession.putValue(...), getValue(...), removeValue(...), getValueNames()

- Add correct SSLSession.getProtocol()

- Ensure OpenSSLEngine.getSession() is thread-safe

- Use optimized AtomicIntegerFieldUpdater when possible

Result:

More complete OpenSslEngine SSLSession implementation

More complete OpenSslEngine SSLSession implementation

Motivation:

The current SSLSession implementation used by OpenSslEngine does not support various operations and so may not be a good replacement by the SSLEngine provided by the JDK implementation.

Modifications:

- Add SSLSession.getCreationTime()

- Add SSLSession.getLastAccessedTime()

- Add SSLSession.putValue(...), getValue(...), removeValue(...), getValueNames()

- Add correct SSLSession.getProtocol()

- Ensure OpenSSLEngine.getSession() is thread-safe

- Use optimized AtomicIntegerFieldUpdater when possible

Result:

More complete OpenSslEngine SSLSession implementation

Refactor LzfDecoder to use proper state machine

Motivation:

Make it much more readable code.

Modifications:

- Added states of decompression.

- Refactored decode(...) method to use this states.

Result:

Much more readable decoder which looks like other compression decoders.

Refactor LzfDecoder to use proper state machine

Motivation:

Make it much more readable code.

Modifications:

- Added states of decompression.

- Refactored decode(...) method to use this states.

Result:

Much more readable decoder which looks like other compression decoders.

Check for errors without object allocation

Motivation:

At the moment we use SSL.getLastError() in unwrap(...) to check for error. This is very inefficient as it creates a new String for each check and we also use a String.startsWith(...) to detect if there was an error we need to handle.

Modifications:

Use SSL.getLastErrorNumber() to detect if we need to handle an error, as this only returns a long and so no String creation happens. Also the detection is much cheaper as we can now only compare longs. Once an error is detected the lately SSL.getErrorString(long) is used to conver the error number to a String and include it in log and exception message.

Result:

Performance improvements in OpenSslEngine.unwrap(...) due less object allocation and also faster comparations.

Check for errors without object allocation

Motivation:

At the moment we use SSL.getLastError() in unwrap(...) to check for error. This is very inefficient as it creates a new String for each check and we also use a String.startsWith(...) to detect if there was an error we need to handle.

Modifications:

Use SSL.getLastErrorNumber() to detect if we need to handle an error, as this only returns a long and so no String creation happens. Also the detection is much cheaper as we can now only compare longs. Once an error is detected the lately SSL.getErrorString(long) is used to conver the error number to a String and include it in log and exception message.

Result:

Performance improvements in OpenSslEngine.unwrap(...) due less object allocation and also faster comparations.

Check for errors without object allocation

Motivation:

At the moment we use SSL.getLastError() in unwrap(...) to check for error. This is very inefficient as it creates a new String for each check and we also use a String.startsWith(...) to detect if there was an error we need to handle.

Modifications:

Use SSL.getLastErrorNumber() to detect if we need to handle an error, as this only returns a long and so no String creation happens. Also the detection is much cheaper as we can now only compare longs. Once an error is detected the lately SSL.getErrorString(long) is used to conver the error number to a String and include it in log and exception message.

Result:

Performance improvements in OpenSslEngine.unwrap(...) due less object allocation and also faster comparations.

Make Bootstrap and ServerBootstrap fully overridable

Related: #2034

Motivation:

Some users want to mock Bootstrap (or ServerBootstrap), and thus they

should not be final but be fully overridable and extensible.

Modifications:

Remove finals wherever possible

Result:

@daschl is happy.

Make Bootstrap and ServerBootstrap fully overridable

Related: #2034

Motivation:

Some users want to mock Bootstrap (or ServerBootstrap), and thus they

should not be final but be fully overridable and extensible.

Modifications:

Remove finals wherever possible

Result:

@daschl is happy.

Make Bootstrap and ServerBootstrap fully overridable

Related: #2034

Motivation:

Some users want to mock Bootstrap (or ServerBootstrap), and thus they

should not be final but be fully overridable and extensible.

Modifications:

Remove finals wherever possible

Result:

@daschl is happy.

Fix an infinite loop when writing a zero-length FileRegion

Related: #2964

Motivation:

Writing a zero-length FileRegion to an NIO channel will lead to an

infinite loop.

Modification:

- Do not write a zero-length FileRegion by protecting with proper 'if'.

- Update the testsuite

Result:

Another bug fixed

Fix an infinite loop when writing a zero-length FileRegion

Related: #2964

Motivation:

Writing a zero-length FileRegion to an NIO channel will lead to an

infinite loop.

Modification:

- Do not write a zero-length FileRegion by protecting with proper 'if'.

- Update the testsuite

Result:

Another bug fixed

Fix an infinite loop when writing a zero-length FileRegion

Related: #2964

Motivation:

Writing a zero-length FileRegion to an NIO channel will lead to an

infinite loop.

Modification:

- Do not write a zero-length FileRegion by protecting with proper 'if'.

- Update the testsuite

Result:

Another bug fixed

Make TestUtils.getFreePort() check both TCP and UDP

Motivation:

We see occational failures in the datagram tests saying 'address already

in use' when we attempt to bind on a port returned by

TestUtils.getFreePort().

It turns out that TestUtils.getFreePort() only checks if TCP port is

available.

Modifications:

Also check if UDP port is available, so that the datagram tests do not

fail because of the 'address already in use' error during a bind

attempt.

Result:

Less chance of datagram test failures