Commit Graph

6321 Commits

Author SHA1 Message Date
Matthias Einwag
a9bd9699a4 Fix the websocket server example
Motivation:
As report in #2953 the websocket server example contained a bug and did therefore not work with chrome:
A websocket extension is added to the pipeline but extensions were disallowed in the handshaker and decoder,
which is leading the decoder to closing the connection after receiving an extension frame.

Modifications:
Allow websocket extensions in the handshaker to correctly enable the extension.

Result:
Working websocket server example
Fixes #2953
2014-10-25 21:48:34 +09:00
Trustin Lee
9b4481b59a Fix a compilation error 2014-10-25 17:13:57 +09:00
Trustin Lee
d794ea515b Fix compilation errors in ChannelOutboundBufferTest 2014-10-25 16:57:47 +09:00
Trustin Lee
83296ca9ac Overall cleanup of 6602fcf54fafeae1d3d0f57734d60f81edc2e0ba 2014-10-25 16:43:11 +09:00
Norman Maurer
32d82fa259 Modify HttpObjectDecoder to allow parsing the HTTP headers in multiple steps.
Motivation:
At the moment the whole HTTP header must be parsed at once which can lead to multiple parsing of the same bytes. We can do better here and allow to parse it in multiple steps.

Modifications:

 - Not parse headers multiple times
 - Simplify the code
 - Eliminate uncessary String[] creations
 - Use readSlice(...).retain() when possible.

Result:

Performance improvements as shown in the included benchmark below.

Before change:
[nmaurer@xxx]~% ./wrk-benchmark
Running 2m test @ http://xxx:8080/plaintext
  16 threads and 256 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    21.55ms   15.10ms 245.02ms   90.26%
    Req/Sec   196.33k    30.17k  297.29k    76.03%
  373954750 requests in 2.00m, 50.15GB read
Requests/sec: 3116466.08
Transfer/sec:    427.98MB

After change:
[nmaurer@xxx]~% ./wrk-benchmark
Running 2m test @ http://xxx:8080/plaintext
  16 threads and 256 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    20.91ms   36.79ms   1.26s    98.24%
    Req/Sec   206.67k    21.69k  243.62k    94.96%
  393071191 requests in 2.00m, 52.71GB read
Requests/sec: 3275971.50
Transfer/sec:    449.89MB
2014-10-25 16:43:11 +09:00
Trustin Lee
329e97f20f Revert "Fix the websocket server example"
This reverts commit 443d686d6a.
2014-10-25 16:43:11 +09:00
Matthias Einwag
443d686d6a Fix the websocket server example
Motivation:
As report in #2953 the websocket server example contained a bug and did therefore not work with chrome:
A websocket extension is added to the pipeline but extensions were disallowed in the handshaker and decoder,
which is leading the decoder to closing the connection after receiving an extension frame.

Modifications:
Allow websocket extensions in the handshaker to correctly enable the extension.

Result:
Working websocket server example
Fixes #2953
2014-10-25 16:18:29 +09:00
Trustin Lee
ee9cbda9f0 Implement user-defined writability flags
Related: #2945

Motivation:

Some special handlers such as TrafficShapingHandler need to override the
writability of a Channel to throttle the outbound traffic.

Modifications:

Add a new indexed property called 'user-defined writability flag' to
ChannelOutboundBuffer so that a handler can override the writability of
a Channel easily.

Result:

A handler can override the writability of a Channel using an unsafe API.
For example:

  Channel ch = ...;
  ch.unsafe().outboundBuffer().setUserDefinedWritability(1, false);
2014-10-25 15:59:30 +09:00
Trustin Lee
5112cec5fa Handle an empty ByteBuf specially in HttpObjectEncoder
Related: #2983

Motivation:

It is a well known idiom to write an empty buffer and add a listener to
its future to close a channel when the last byte has been written out:

  ChannelFuture f = channel.writeAndFlush(Unpooled.EMPTY_BUFFER);
  f.addListener(ChannelFutureListener.CLOSE);

When HttpObjectEncoder is in the pipeline, this still works, but it
silently raises an IllegalStateException, because HttpObjectEncoder does
not allow writing a ByteBuf when it is expecting an HttpMessage.

Modifications:

- Handle an empty ByteBuf specially in HttpObjectEncoder, so that
  writing an empty buffer does not fail even if the pipeline contains an
  HttpObjectEncoder
- Add a test

Result:

An exception is not triggered anymore by HttpObjectEncoder, when a user
attempts to write an empty buffer.
2014-10-22 14:45:02 +09:00
Daniel Bevenius
a9dcdf8864 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.
2014-10-22 06:38:15 +02:00
Trustin Lee
4e005b470f Fix missing version properties of transport-epoll in all-in-one JAR
Related: #2952

Motivation:

META-INF/io.netty.versions.properties in netty-all-*.jar does not
contain the version information about the netty-transport-epoll module.

Modifications:

Fix a bug in the regular expression in pom.xml, so that the artifacts
with a classifier is also included in the version properties file.

Result:

The version information of all modules are included in the version
properties file, and Version.identify() does not miss
netty-transport-epoll.
2014-10-21 22:31:46 +09:00
Frederic Bregier
2fc421b2ba Backport 4.1 to 4.0 on HttpPostRequestDecoder
Motivation
4.0 was not modified in the same time than 4.1 while the difference was
limited.
Include the fix on "=" character in Boundary.

Issue #3004 shows that "=" character was not supported as it should in
the HttpPostRequestDecoder in form-data boundary.

Modifications:
Backport from 4.1 to 4.0 while respecting interfaces.

Add 2 methods in StringUtil
- split with maxParm argument: String split with max parts only (to prevent multiple '='
to be source of extra split while not needed)
- substringAfter: String part after delimiter (since first part is not
needed)
Use those methods in HttpPostRequestDecoder.
Change and the HttpPostRequestDecoderTest to check using a boundary
beginning with "=".

Results:
Backport done (Issue #2886 fix)
Issue #3004 fix too
The fix implies more stability and fix the relative issues.
2014-10-21 16:05:08 +09:00
Trustin Lee
6150de5eb2 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
2014-10-21 14:01:04 +09:00
nmittler
76de0a7567 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.
2014-10-20 12:39:25 -07:00
nmittler
c6053b8698 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().
2014-10-20 10:59:27 -07:00
nmittler
c1217b9dd3 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.
2014-10-20 18:08:26 +02:00
Trustin Lee
d36950503c 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.
2014-10-17 16:17:48 +09:00
Trustin Lee
c13f72c5b6 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
2014-10-17 16:06:57 +09:00
Trustin Lee
8416a47106 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
2014-10-17 15:05:01 +09:00
Trustin Lee
2443005c15 Do not consider PortUnreachableException to require channel closure
Motivation:

When a datagram packet is sent to a destination where nobody actually listens to,
the server O/S will respond with an ICMP Port Unreachable packet.
The ICMP Port Unreachable packet is translated into PortUnreachableException by JDK.
PortUnreachableException is not a harmful exception that prevents a user from sending a datagram.
Therefore, we should not close a datagram channel when PortUnreachableException is caught.

Modifications:

- Do not close a channel when the caught exception is PortUnreachableException.

Result:

A datagram channel is not closed unexpectedly anymore.
2014-10-14 17:50:31 +09:00
Trustin Lee
f0e2aa424d Add AbstractUnsafe.annotateConnectException()
Motivation:

JDK's exception messages triggered by a connection attempt failure do
not contain the related remote address in its message.  We currently
append the remote address to ConnectException's message, but I found
that we need to cover more exception types such as SocketException.

Modifications:

- Add AbstractUnsafe.annotateConnectException() to de-duplicate the
  code that appends the remote address

Result:

- Less duplication
- A transport implementor can annotate connection attempt failure
  message more easily
2014-10-14 17:50:31 +09:00
Trustin Lee
31862cca18 Fix a bug in NetUtil.createByteArrayFromIpAddressString()
Motivation:

An IPv6 string can have a zone index which is followed by the '%' sign.
When a user passes an IPv6 string with a zone index,
NetUtil.createByteArrayFromIpAddressString() returns an incorrect value.

Modification:

- Strip the zone index before conversion

Result:

An IPv6 string with a zone index is decoded correctly.
2014-10-14 17:50:31 +09:00
Matthias Einwag
730525c6cf Add verification for websocket subprotocol on the client side.
Motivation:

Websocket clients can request to speak a specific subprotocol. The list of
subprotocols the client understands are sent to the server. The server
should select one of the protocols an reply this with the websocket
handshake response. The added code verifies that the reponded subprotocol
is valid.

Modifications:

Added verification of the subprotocol received from the server against the
subprotocol(s) that the user requests. If the user requests a subprotocol
but the server responds none or a non-requested subprotocol this is an
error and the handshake fails through an exception. If the user requests
no subprotocol but the server responds one this is also marked as an
error.

Addiontionally a getter for the WebSocketClientHandshaker in the
WebSocketClientProtocolHandler is added to enable the user of a
WebSocketClientProtocolHandler to extract the used negotiated subprotocol.

Result:

The subprotocol field which is received from a websocket server is now
properly verified on client side and clients and websocket connection
attempts will now only succeed if both parties can negotiate on a
subprotocol.
If the client sends a list of multiple possible subprotocols it can
extract the negotiated subprotocol through the added handshaker getter (WebSocketClientProtocolHandler.handshaker().actualSubprotocol()).
2014-10-14 14:47:11 +09:00
Luke Wood
bcfd6da1dd Access autoRead via an AtomicIntegerFieldUpdater.
Motiviation:

Before this change, autoRead was a volatile boolean accessed directly.  Any thread that invoked the DefaultChannelConfig#setAutoRead(boolean) method would read the current value of autoRead, and then set a new value.  If the old value did not match the new value, some action would be immediately taken as part of the same method call.

As volatile only provides happens-before consistency, there was no guarantee that the calling thread was actually the thread mutating the state of the autoRead variable (such that it should be the one to invoke the follow-up actions).  For example, with 3 threads:
 * Thread 1: get = false
 * Thread 1: set = true
 * Thread 1: invokes read()
 * Thread 2: get = true
 * Thread 3: get = true
 * Thread 2: set = false
 * Thread 2: invokes autoReadCleared()
 * Event Loop receives notification from the Selector that data is available, but as autoRead has been cleared, cancels the operation and removes read interest
 * Thread 3: set = true

This results in a livelock - autoRead is set true, but no reads will happen even if data is available (as readyOps).  The only way around this livelock currently is to set autoRead to false, and then back to true.

Modifications:

Write access to the autoRead variable is now made using the getAndSet() method of an AtomicIntegerFieldUpdater, AUTOREAD_UPDATER.  This also changed the type of the underlying autoRead variable to be an integer, as no AtomicBooleanFieldUpdater class exists.  Boolean logic is retained by assuming that 1 is true and 0 is false.

Result:

There is no longer a race condition between retrieving the old value of the autoRead variable and setting a new value.
2014-10-13 15:16:28 +02:00
Matthias Einwag
a13ad3367c Add a test for handover from HTTP to Websocket
Motivation:
I was not fully reassured that whether everything works correctly when a websocket client receives the websocket handshake HTTP response and a websocket frame in a single ByteBuf (which can happen when the server sends a response directly or shortly after the connect). In this case some parts of the ByteBuf must be processed by HTTP decoder and the remaining by the websocket decoder.

Modification:
Adding a test that verifies that in this scenaria the handshake and the message are correctly interpreted and delivered by Netty.

Result:
One more test for Netty.
The test succeeds - No problems
2014-10-13 07:23:31 +02:00
Matthias Einwag
feda7afc0b Adding a benchmark for websockets
Motivation:

It is often helpful to measure the performance of connections, e.g. the
latency and the throughput. This can be performed through benchmarks.

Modification:

This adds a simple but configurable benchmark for websockets into the
example directory. The Netty WebSocket server will echo all received
websocket frames and will provide an HTML/JS page which serves as the
client for the benchmark.
The benchmark also provides a verification mode that verifies the sent
against the received data. This can be used for the verification ob
websocket frame encoding and decoding funtionality.

Result:

A benchmark is added in form a further Netty websocket example.
With this benchmark it is easily possible to measure the performance between Netty and a browser
2014-10-13 07:13:56 +02:00
Matthias Einwag
9f077b41b0 Fix the leak in the WebSocketClientProtocolHandshakeHandler
Motivation:
The WebSocketClientProtocolHandshakeHandler never releases the received handshake response.

Modification:
Release the message in a finally block.

Result:
No more leak
2014-10-12 20:26:34 +02:00
Matthias Einwag
abb06779c8 Avoid vectored writes for small websocket messages
Motivation:
The WebSocket08FrameEncoder contains an optimization path for small messages which copies the message content into the header buffer to avoid vectored writes. However this path is in the current implementation never taken because the target buffer is preallocated only for exactly the size of the header.

Modification:
For messages below a certain treshold allocate the buffer so that the message can be directly copied. Thereby the optimized path is taken.

Result:
A speedup of about 25% for 100byte messages. Declines with bigger message sizes. I have currently set the treshold to 1kB which is a point where I could still see a few percent speedup, but we should also avoid burning too many CPU cycles.
2014-10-12 20:08:57 +02:00
Matthias Einwag
2af04ea2ee Improve WebSocket performance
Motivation:

Websocket performance is to a large account determined through the masking
and unmasking of frames. The current behavior of this in Netty can be
improved.

Modifications:

Perform the XOR operation not bytewise but in int blocks as long as
possible. This reduces the number of necessary operations by 4. Also don't
read the writerIndex in each iteration.
Added a unit test for websocket decoding and encoding for verifiation.

Result:

A large performance gain (up to 50%) in websocket throughput.
2014-10-12 20:07:25 +02:00
kerr
a57408ebfc Change the operator order of TrafficCounter to calculate the throughput to get the correct result
Motivation:
Currently the last read/write throughput is calculated by first division,this will be 0 if the last read/write bytes < interval,change the order will get the correct result

Modifications:
Change the operator order from first do division to multiplication

Result:
Get the correct result instead of 0 when bytes are smaller than interval
2014-10-01 06:45:17 +02:00
Matthias Einwag
ea3c26b65e Send a websocket close frame with status code when receiving invalid frames
Motivation:

According to the websocket specification peers may send a close frame when
they detect a protocol violation (with status code 1002). The current
implementation simply closes the connection. This update should add this
functionality. The functionality is optional - but it might help other
implementations with debugging when they receive such a frame.

Modification:

When a protocol violation in the decoder is detected and a close was not
already initiated by the remote peer a close frame is
sent.

Result:

Remotes which will send an invalid frame will now get a close frame that
indicates the protocol violation instead of only seeing a closed
connection.
2014-09-29 20:31:23 +02:00
Norman Maurer
01b0691ee0 [#2939] Fix SslContext usage in the examples for client side
Motivation:

We incorrectly used SslContext.newServerContext() in some places where a we needed a client context.

Modifications:

Use SslContext.newClientContext() when using ssl on the client side.

Result:

Working ssl client examples.
2014-09-26 20:59:25 +02:00
Norman Maurer
9968c61fbe [#2926] Fix 1 byte memory leak in native transport
Motivation:

We use malloc(1) in the on JNI_OnLoad method but never free the allocated memory. This means we have a tiny memory leak of 1 byte.

Modifications:

Call free(...) on previous allocated memory.

Result:

Fix memory leak
2014-09-22 15:07:40 +02:00
Norman Maurer
cb85ed9d66 Disable caching of PooledByteBuf for different threads.
Motivation:

We introduced a PoolThreadCache which is used in our PooledByteBufAllocator to reduce the synchronization overhead on PoolArenas when allocate / deallocate PooledByteBuf instances. This cache is used for both the allocation path and deallocation path by:
  - Look for cached memory in the PoolThreadCache for the Thread that tries to allocate a new PooledByteBuf and if one is found return it.
  - Add the memory that is used by a PooledByteBuf to the PoolThreadCache of the Thread that release the PooledByteBuf

This works out very well when all allocation / deallocation is done in the EventLoop as the EventLoop will be used for read and write. On the otherside this can lead to surprising side-effects if the user allocate from outside the EventLoop and and pass the ByteBuf over for writing. The problem here is that the memory will be added to the PoolThreadCache that did the actual write on the underlying transport and not on the Thread that previously allocated the buffer.

Modifications:

Don't cache if different Threads are used for allocating/deallocating

Result:

Less confusing behavior for users that allocate PooledByteBufs from outside the EventLoop.
2014-09-22 13:38:35 +02:00
Norman Maurer
687d3d3b5c [#2924] Correctly update head in MemoryRegionCache.trim()
Motivation:
When MemoryRegionCache.trim() is called, some unused cache entries will be freed (started from head). However, in MeoryRegionCache.trim() the head is not updated, which make entry list's head point to an entry whose chunk is null now and following allocate of MeoryRegionCache will return false immediately.

In other word, cache is no longer usable once trim happen.

Modifications:

Update head to correct idx after free entries in trim().

Result:

MemoryRegionCache behaves correctly even after calling trim().
2014-09-22 10:56:17 +02:00
Frederic Bregier
9479cdd0d4 Fix overriden method not called in TrafficShaping
Motivation:
handlerAdded and handlerRemoved were overriden but super was never
called, while it should.
Also add one missing information in the toString method.

Modifications:
Add the super corresponding call, and add checkInterval to the
toString() method

Result;
super method calls are correctly passed to the super implementation
part.
2014-09-20 20:41:00 +02:00
Norman Maurer
6175fc49d4 Allow to access uri of QueryStringDecoder. Related to [#2896]
Motivation:

Sometimes it is useful to be able to access the uri that was used to initialize the QueryStringDecoder.

Modifications:

Add method which allows to retrieve the uri.

Result:

Allow to retrieve the uri that was used to create the QueryStringDecoder.
2014-09-19 20:06:22 +02:00
Wolfgang Profer
aa376b51de Fixed FingerprintTrustManagerFactory constructor
Motivation:

When constructing a FingerprintTrustManagerFactory from an Iterable of Strings, the fingerprints were correctly parsed but never added to the result array. The constructed FingerprintTrustManagerFactory consequently fails to validate any certificate.

Modifications:

I added a line to add each converted SHA-1 certificate fingerprint to the result array which then gets passed on to the next constructor.

Result:

Certificate fingerprints passed to the constructor are now correctly added to the array of valid fingerprints. The resulting FingerprintTrustManagerFactory object correctly validates certificates against the list of specified fingerprints.
2014-09-19 19:49:19 +02:00
Scott Mitchell
b9582f4329 Fix Native EPOLL Build Failure
Motiviation:
If sendmmsg is already defined then the native epoll module failed to build because of conflicting definitions.
The mmsghdr type was also redefined on systems that already supported this structure.

Modifications:
Provide a way so that systems which already define sendmmsg and mmsghdr can build
Provide a way so that systems which don't define sendmmsg and mmsghdr can build

Result:
The native EPOLL module can build in more environments
2014-09-17 20:59:47 +02:00
Barber, Francis
7339394484 Add support for ExtensionRegistryLite in ProtobufDecoder
Motivation:

ExtensionRegistry is a subclass of ExtensionRegistryLite.  The ProtobufDecoder
doesn't use the registry directly, it simply passes it through to the Protobuf
API.  The Protobuf calls in question are themselves written in terms
ExtensionRegistryLite not ExtensionRegistry.

Modifications:

Require ExtensionRegistryLite instead of ExtensionRegistry in ProtobufDecoder.

Result:

Consumers can use ExtensionRegistryLite with ProtobufDecoder.
2014-09-15 07:06:30 +02:00
Brad Fritz
17e55c7d7b Correct javadoc typo in IdleStateHandler example code 2014-09-10 20:55:25 +02:00
Scott Mitchell
dce21483e3 HTTP Content Decoder Cleanup Bug
Motiviation:
The HTTP content decoder's cleanup method is not cleaning up the decoder correctly.
The cleanup method is currently doing a readOutbound on the EmbeddedChannel but
for decoding the call should be readInbound.

Modifications:
-Change readOutbound to readInbound in the cleanup method

Result:
The cleanup method should be correctly releaseing unused resources
2014-09-10 14:54:25 +02:00
Norman Maurer
b4feb7ac19 Directly write CompositeByteBuf if possible without memory copy. Related to [#2719]
Motivation:

In linux it is possible to write more then one buffer withone syscall when sending datagram messages.

Modifications:

Not copy CompositeByteBuf if it only contains direct buffers.

Result:

More performance due less overhead for copy.
2014-09-10 14:30:58 +02:00
Norman Maurer
fcb80e34ca Fix buffer leak in DatagramUnicastTest caused by incorrect usage of CompositeByteBuf
Motivation:

Due incorrect usage of CompositeByteBuf a buffer leak was introduced.

Modifications:

Correctly handle tests with CompositeByteBuf.

Result:

No more buffer leaks
2014-09-10 11:40:53 +02:00
Norman Maurer
7867f986fa Add support for sendmmsg(...) and so allow to write multiple DatagramPackets with one syscall. Related to [#2719]
Motivation:

On linux with glibc >= 2.14 it is possible to send multiple DatagramPackets with one syscall. This can be a huge performance win and so we should support it in our native transport.

Modification:

- Add support for sendmmsg by reuse IovArray
- Factor out ThreadLocal support of IovArray to IovArrayThreadLocal for better separation as we use IovArray also without ThreadLocal in NativeDatagramPacketArray now
- Introduce NativeDatagramPacketArray which is used for sendmmsg(...)
- Implement sendmmsg(...) via jni
- Expand DatagramUnicastTest to test also sendmmsg(...)

Result:

Netty now automatically use sendmmsg(...) if it is supported and we have more then 1 DatagramPacket in the ChannelOutboundBuffer and flush() is called.
2014-09-09 09:43:07 +02:00
Norman Maurer
07876ebf68 Allow to write CompositeByteBuf directly via EpollDatagramChannel. Related to [#2719]
Motivation:

On linux it is possible to use the sendMsg(...) system call to write multiple buffers with one system call when using datagram/udp.

Modifications:

- Implement the needed changes and make use of sendMsg(...) if possible for max performance
- Add tests that test sending datagram packets with all kind of different ByteBuf implementations.

Result:

Performance improvement when using CompoisteByteBuf and EpollDatagramChannel.
2014-09-09 09:43:07 +02:00
Norman Maurer
6d1b96fb63 [#2867] Workaround performance issue with IPv4-mapped-on-IPv6 addresses
Motivation:

InetAddress.getByName(...) uses exceptions for control flow when try to parse IPv4-mapped-on-IPv6 addresses. This is quite expensive.

Modifications:

Detect IPv4-mapped-on-IPv6 addresses in the JNI level and convert to IPv4 addresses before pass to InetAddress.getByName(...) (via InetSocketAddress constructor).

Result:

Eliminate performance problem causes by exception creation when parsing IPv4-mapped-on-IPv6 addresses.
2014-09-09 06:36:40 +02:00
Norman Maurer
0bab6116f3 [#2843] Add test-case to show correct behavior of ByteBuf.refCnt() and ByteBuf.release(...)
Motivation:

We received a bug-report that the ByteBuf.refCnt() does sometimes not show the correct value when release() and refCnt() is called from different Threads.

Modifications:

Add test-case which shows that all is working like expected

Result:

Test-case added which shows everything is ok.
2014-09-01 08:48:15 +02:00
Amir Szekely
fe785c2308 Don't ignore maxCapacity if it's not a power of 2
Motivation:

This fixes bug #2848 which caused Recycler to become unbounded and cache infinite number of objects with maxCapacity that's not a power of two. This can result in general sluggishness of the application and OutOfMemoryError.

Modifications:

The test for maxCapacity has been moved out of test to check if the buffer has filled. The buffer is now also capped at maxCapacity and cannot grow over it as it jumps from one power of two to the other.

Additionally, a unit test was added to verify maxCapacity is honored even when it's not a power of two.

Result:

With these changes the user is able to use a custom maxCapacity number and not have it ignored. The unit test assures this bug will not repeat itself.
2014-08-31 09:11:01 +02:00
Norman Maurer
b9101b0331 [#2823] Writing DefaultFileRegion with EpollSocketChannel may cause hang
Motivation:

In EpollSocketchannel.doWriteFileRegion(...) we need to make sure we write until sendFile(...) returns either 0 or all is written. Otherwise we may not get notified once the Channel is writable again.

This is the case as we use EPOLL_ET.

Modifications:

Always write until either sendFile returns 0 or all is written.

Result:

No more hangs when writing DefaultFileRegion can happen.
2014-08-26 15:07:02 +02:00