Commit Graph

6713 Commits

Author SHA1 Message Date
Trustin Lee
c453c3ce0d Do now swallow an exception triggered by late listener notification
Related: #3449

Motivation:

When a user shut down an EventExecutor/Loop prematurely, a Promise will
fail to execute its listeners. When it happens, DefaultPromise will log
a message at ERROR level, but there's no way to get notified about it
programmatically.

Modifications:

Do not catch and log the RejectedExecutionException unconditionally,
but only catch and log for non-late listener notifications, so that a
user gets notified on submission failure at least when the listener is
late.

Result:

Remedies #3449 to some extent, although we will need fundamental fix for
that, such as #3566
2016-04-06 11:16:58 +02:00
Norman Maurer
2e68e37025 [#5028] Fix re-entrance issue with channelWritabilityChanged(...) and write(...)
Motivation:

When always triggered fireChannelWritabilityChanged() directly when the update the pending bytes in the ChannelOutboundBuffer was made from within the EventLoop. This is problematic as this can cause some re-entrance issue if the user has a custom ChannelOutboundHandler that does multiple writes from within the write(...) method and also has a handler that will intercept the channelWritabilityChanged event and trigger another write when the Channel is writable. This can also easily happen if the user just use a MessageToMessageEncoder subclass and triggers a write from channelWritabilityChanged().

Beside this we also triggered fireChannelWritabilityChanged() too often when a user did a write from outside the EventLoop. In this case we increased the pending bytes of the outboundbuffer before scheduled the actual write and decreased again before the write then takes place. Both of this may trigger a fireChannelWritabilityChanged() event which then may be re-triggered once the actual write ends again in the ChannelOutboundBuffer.

The third gotcha was that a user may get multiple events even if the writability of the channel not changed.

Modification:

- Always invoke the fireChannelWritabilityChanged() later on the EventLoop.
- Only trigger the fireChannelWritabilityChanged() if the channel is still active and if the writability of the channel changed. No need to cause events that were already triggered without a real writability change.
- when write(...) is called from outside the EventLoop we only increase the pending bytes in the outbound buffer (so that Channel.isWritable() is updated directly) but not cause a fireChannelWritabilityChanged(). The fireChannelWritabilityChanged() is then triggered once the task is picked up by the EventLoop as usual.

Result:

No more re-entrance possible because of writes from within channelWritabilityChanged(...) method and no events without a real writability change.
2016-04-06 10:50:41 +02:00
Norman Maurer
a034c1cfc6 Fix PoolChunkList.minUsage() and maxUsage() for head and tail
Motivation:

The PoolChunkList.minUsage() and maxUsage() needs to take special action to translate Integer.MIN_VALUE / MAX_VALUE as these are used internal for tail and head of the linked-list structure.

Modifications:

- Correct the minUsage() and maxUsage() methods.
- Add unit test.

Result:

Correct metrics
2016-04-06 10:03:14 +02:00
Scott Mitchell
4506bbd27b fcbeebf6df unit test bug
Motivation:
fcbeebf6df introduced a unit test to verify ApplicationProtocolNegotiationHandler is compatible with SniHandler. However only the server attempts ALPN and verifies that it completes and the client doesn't verify the handshake is completed. This can lead to the client side SSL engine to prematurely close and throw an exception.

Modifications:
- The client should wait for the SSL handshake and ALPN to complete before the test exits.

Result:
SniHandlerTest.testSniWithApnHandler is more reliable.
2016-04-06 00:12:54 -07:00
Norman Maurer
61ae4a3a78 Include cause that was used to notify the promise when logging an failed try to notify it.
Motivation:

When a promise is notified that was already added to the ChannelOutboundBuffer and we try to notify it later on we only see a warning that it was notified before. This is often not very useful as we have no idea where it was notified at all. We can do better in case it was failed before (which is most of the times the case) and just also log the cause that was used for it.

Modifications:

Add the cause that was used to notify the promise when we fail to notify it as part of the ChannelOutboundBuffer.

Result:

Easier to debug user errors.
2016-04-05 21:13:00 +02:00
Xiaoyan Lin
35c5664a64 Add Log4J2LoggerFactory and Log4J2Logger
Motivation:

See #3095

Modifications:

Add Log4J2LoggerFactory and Log4J2Logger which is an InternalLogger implementation based on log4j2.

Result:

The user can use log4j2 directly without a special slf4j binding.
2016-04-05 14:07:26 +02:00
Norman Maurer
6a1c5611ab Allow to disable leak detection for all buffers when using UnpooledByteBufAllocator.
Motivation:

Sometimes it is useful to allow to disable the leak detection of buffers if the UnpooledByteBufAllocator is used. This is for example true if the app wants to leak buffers into user code but not want to put the burden on the user to always release the buffer.

Modifications:

Add another constructor to UnpooledByteBufAllocator that allows to completely disable leak-detection for all buffers that are allocator out of the UnpooledByteBufAllocator.

Result:

It's possible to disable leak-detection when the UnpooledByteBufAllocator is used.
2016-04-05 13:20:15 +02:00
Norman Maurer
5a0d0daed3 Only increment metric for huge / normal allocations after the allocation was really done.
Motivation:

We should only increment the metric for the huge / normal allocation after it is done. Also we should only decrement once deallocate.

Modifications:

- Move increment after the allocation.
- Fix deallocation metric and move it after deallocation

Result:

More correct metrics.
2016-04-05 12:00:58 +02:00
Norman Maurer
2547438783 PoolThreadCache uses wrong variable in IllegalArgumentException
Motivation:

PoolThreadCache includes the wrong value when throwing a IllegalArgumentException because of freeSweepAllocationThreshold.

Modifications:

Use the correct value.

Result:

Correct exception message.
2016-04-05 11:48:59 +02:00
Scott Mitchell
2263d9b46b ApplicationProtocolNegotiationHandler doesn't work with SniHandler
Motivation:
ApplicationProtocolNegotiationHandler attempts to get a reference to an SslHandler in handlerAdded, but when SNI is in use the actual SslHandler will be added to the pipeline dynamically at some later time. When the handshake completes ApplicationProtocolNegotiationHandler throws an IllegalStateException because its reference to SslHandler is null.

Modifications:
- Instead of saving a reference to SslHandler in handlerAdded just search the pipeline when the SslHandler is needed

Result:
ApplicationProtocolNegotiationHandler support SniHandler.
Fixes https://github.com/netty/netty/issues/5066
2016-04-05 09:03:07 +02:00
Norman Maurer
4b6b167839 [maven-release-plugin] prepare for next development iteration 2016-04-04 16:53:40 +02:00
Norman Maurer
e8fa848f43 [maven-release-plugin] prepare release netty-4.0.36.Final 2016-04-04 16:52:53 +02:00
Norman Maurer
47baeb5ded [maven-release-plugin] rollback the release of netty-4.0.36.Final 2016-03-29 22:58:32 +02:00
Norman Maurer
29a4f3e363 [maven-release-plugin] prepare release netty-4.0.36.Final 2016-03-29 21:30:50 +02:00
Tibor Csögör
4fdf0e8026 ChannelInitializer: change propagation of channelRegistered event
Motivation:

If a handler is added to the pipeline within ChannelInitializer::initChannel via
addFirst(...) then it will not receive the channelRegistered event.  The same
handler added via addLast(...) will receive the event.  This different behavior
is unlikely to be expected by users and can cause confusion.

Modifications:

Let ChannelInitializer::channelRegistered propagate the event by passing it to
the pipeline instead of firing it on the ChannelHandlerContext.

Result:

The channelRegistered event is propagated to handlers regardless of the method
used to add it to the pipeline (addFirst/addLast).
2016-03-31 09:26:42 +02:00
Scott Mitchell
a6d6a15ce6 EPOLL SelectStrategy
Motivation:
NIO now supports a pluggable select strategy, but EPOLL currently doesn't support this. We should strive for feature parity for EPOLL.

Modifications:
- Add SelectStrategy to EPOLL transport.

Result:
EPOLL transport supports SelectStategy.
2016-03-30 15:03:46 -07:00
Michael Nitschinger
24cb673468 Allow to customize NIO (channel) select strategies.
Motivation:

Under high throughput/low latency workloads, selector wakeups are
degrading performance when the incoming operations are triggered
from outside of the event loop. This is a common scenario for
"client" applications where the originating input is coming from
application threads rather from the socket attached inside the
event loops.

As a result, it can be desirable to defer the blocking select
so that incoming tasks (write/flush) do not need to wakeup
the selector.

Modifications:

This changeset adds the notion of a generic SelectStrategy which,
based on its contract, allows the implementation to optionally
defer the blocking select based on some custom criteria.

The default implementation resembles the original behaviour, that
is if tasks are in the queue `selectNow()` and move on, and if no
tasks need to be processed go into the blocking select and wait
for wakeup.

The strategy can be customized per `NioEventLoopGroup` in the
constructor.

Result:

High performance client applications are now given the chance to
customize for how long the actual selector blocking should be
deferred by employing a custom select strategy.
2016-03-30 14:46:43 -07:00
Norman Maurer
949bfdf8c5 [#5045] Fix websockets server example which was broken by 2e6544f
Motivation:

While backport the change from 4.1 to 4.0 I somehow missed to port one line and so broke the example.

Modifications:

Add needed handler which was missing due bad merge commit.

Result:

Example works again in 4.0
2016-03-30 10:23:32 +02:00
Norman Maurer
6a4a9f7493 Correctly run pending tasks before flush and also remove incorrect assert.
Motivation:

We need to ensure we run all pending tasks before doing any flush in writeOutbound(...) to ensure all pending tasks are run first. Also we should remove the assert of the future and just add a listener to it so it is processed later if needed. This is true as a user may schedule a write for later execution.

Modifications:

- Remove assert of future in writeOutbound(...)
- Correctly run pending tasks before doing the flush and also before doing the close of the channel.
- Add unit tests to proof the defect is fixed.

Result:

Correclty handle the situation of delayed writes.
2016-03-29 14:30:47 +02:00
Norman Maurer
900db0acff Not attempt to read from fd when channel is closed during read loop. Related to [#5031]
Motivation:

We need to break out of the read loop for two reasons:

- If the input was shutdown in between (which may be the case when the user did it in the
  fireChannelRead(...) method we should not try to read again to not produce any
  miss-leading exceptions.

- If the user closes the channel we need to ensure we not try to read from it again as
  the filedescriptor may be re-used already by the OS if the system is handling a lot of
  concurrent connections and so needs a lot of filedescriptors. If not do this we risk
  reading data from a filedescriptor that belongs to another socket then the socket that
  was "wrapped" by this Channel implementation.

Modification:

Break the reading loop if the input was shutdown from within the channelRead(...) method.

Result:

No more meaningless exceptions and no risk to read data from wrong socket after the original was closed.

Conflicts:
	transport-native-epoll/src/main/java/io/netty/channel/epoll/AbstractEpollStreamChannel.java
2016-03-29 10:56:54 +02:00
Vladimir Kostyukov
ea4a8e339c Read if needed on NEED_UNWRAP
Motivation:

There are some use cases when a client may only be willing to read from a channel once
its previous write is finished (eg: serial dispatchers in Finagle). In this case, a
connection with SslHandler installed and ctx.channel().config().isAutoRead() == false
will stall in 100% of cases no matter what order of "channel active", "write", "flush"
events was.

The use case is following (how Finagle serial dispatchers work):

1. Client writeAndFlushes and waits on a write-promise to perform read() once it's satisfied.
2. A write-promise will only be satisfied once SslHandler finishes with handshaking and
   sends the unencrypted queued message.
3. The handshaking process itself requires a number of read()s done by a client but the
   SslHandler doesn't request them explicitly assuming that either auto-read is enabled
   or client requested at least one read() already.
4. At this point a client will stall with NEED_UNWRAP status returned from underlying engine.

Modifiations:

Always request a read() on NEED_UNWRAP returned from engine if

a) it's handshaking and
b) auto read is disabled and
c) it wasn't requested already.

Result:

SslHandler is now completely tolerant of whether or not auto-read is enabled and client
is explicitly reading a channel.
2016-03-29 08:48:08 +02:00
Norman Maurer
e537c6b472 [#4637] More helpful exception message when a non PKCS#8 key is used.
Motivation:

We should throw a more helpful exception when a non PKCS#8 key is used by the user.

Modifications:

Change exception message to give a hint what is wrong.

Result:

Easier for user to understand whats wrong with their used key.
2016-03-27 20:19:54 +02:00
Scott Mitchell
4d0e76e561 EPOLL Socket Shutdown Fix
Motivation:
8dbf5d02e5 modified the shutdown code for Socket but did not correctly calculate the change in shutdown state and only applying this change. This is significant because if sockets are being opening and closed quickly and the underlying FD happens to be reused we need to take care that we don't unintentionally change the state of the new FD by acting on an object which represents the old incarnation of that FD.

Modifications:
- Calculate the shutdown change, and only apply what has changed, or exit if no change.

Result:
Socket.shutdown can not inadvertently affect the state of another logical FD.
2016-03-25 12:01:17 -07:00
Norman Maurer
ad85014110 [#5033] Fix typo in exception message introduced by acbca192bd
Motivation:

I introduced a typo as part of acbca192bd.

Modifications:

Fix typo

Result:

Correct message in exception.
2016-03-24 16:25:56 +01:00
Norman Maurer
b6c320bd0a Add methods to easily release messages from inbound / outbound buffer of EmbeddedChannel
Motivation:

Often the user uses EmbeddedChannel within unit tests where the only "important" thing is to know if any pending messages were in the buffer and then release these.
We should provide methods for this so the user not need to manually loop through these and release.

Modifications:

Add methods to easily handle releasing of messages.

Result:

Less boiler-plate code for the user to write.
2016-03-24 11:15:29 +01:00
Norman Maurer
ad5c3103bc [#5029] Fix type of EpollChannelOption.TCP_QUICKACK
Motivation:

TCP_QUICKACK uses Integer but needs to be Boolean

Modifications:

Fix type

Result:

Be able to use EpollChannelOption.TCP_QUICKACK
2016-03-18 01:11:03 +01:00
Xiaoyan Lin
4608ecf374 Backport InternalThreadLocalMap reusable ArrayList
Motivation:

See https://github.com/netty/netty/issues/3411.
Backport perf improvements on 4.0 and make AsyncHttpClient DNS modules
backports easier to maintain.

Modifications:

Cherry-picked b7415a3307

Result:

Reuse a thread local ArrayList to avoid allocations.
2016-03-23 17:29:00 +01:00
Norman Maurer
fdefbba9a0 Upgrade netty-tcnative to 1.1.33.Fork15
Motivation:

We should upgrade to latest netty-tcnative version.

Modifications:

Upgrade to version 1.1.33.Fork15

Result:

Latest netty-tcnative version is used.
2016-03-23 11:46:05 +01:00
Xiaoyan Lin
f5b4937543 Speed up the slow path of FastThreadLocal
Motivation:

The current slow path of FastThreadLocal is much slower than JDK ThreadLocal. See #4418

Modifications:

- Add FastThreadLocalSlowPathBenchmark for the flow path of FastThreadLocal
- Add final to speed up the slow path of FastThreadLocal

Result:

The slow path of FastThreadLocal is improved.
2016-03-23 11:44:30 +01:00
Norman Maurer
2308f1703b Cleanup transport-native-epoll code.
Motivation:

The code of transport-native-epoll missed some things in terms of static keywords, @deprecated annotations and other minor things.

Modifications:

- Add missing @deprecated annotation
- Not using FQCN in javadocs
- Add static keyword where possible
- Use final fields when possible
- Remove throws IOException from method where it is not needed.

Result:

Cleaner code.

Conflicts:
	transport-native-epoll/src/main/java/io/netty/channel/epoll/AbstractEpollChannel.java
	transport-native-epoll/src/main/java/io/netty/channel/epoll/EpollDatagramChannel.java
	transport-native-epoll/src/main/java/io/netty/channel/epoll/EpollRecvByteAllocatorHandle.java
2016-03-17 21:36:47 +01:00
Bruno Harbulot
f5fab38988 Using distinct aliases when building the trust manager factory, and renamed trustCertChain into trustCertCollection.
Motivation:

SSLContext.buildTrustManagerFactory(...) builds a KeyStore to
initialize the TrustManagerFactory from an array of X509Certificates,
assuming that array is a chain and that each certificate will have a
unique Subject Distinguised Name.
However, the collection of certificates used as trust anchors is generally
not a chain (it is an unordered collection), and it is legitimate for it
to contain multiple certificates with the same Subject DN.
The existing code uses the Subject DN as the alias name when filling in
the `KeyStore`, thereby overwriting other certificates with the same
Subject DN in this collection, so some certificates may be discarded.
In addition, the code related to building trust managers can take an array of
X509Certificate instances to use as trust anchors. The variable name is
usually trustCertChain, and the documentation refers to them as a "chain".
However, while it makes sense to talk about a "chain" from a keymanager
point of view, these certificates are just an unordered collection in a
trust manager. (There is no chaining requirement, having the Subject DN
matching its predecessor's Issuer DN.)
This can create confusion to for users not used with PKI concepts.

Modifications:

SSLContext.buildTrustManagerFactory(...) now uses a distinct alias for each
array (simply using a counter, since this name is never used for reference
later). This patch also includes a unit test with CA certificates using the
same Subject DN.
Also renamed trustCertChain into trustCertCollection, and changed the
references to "chain" in the Javadoc.

Result:

Each loaded certificate now has a unique identifier when loaded, so it is
now possible to use multiple certificates with the same Subject DN as
trust anchors.
Hopefully, renaming the parameter should also reduce confusion around PKI
concepts.
2016-03-22 21:29:33 +01:00
Stephane Landelle
1d9c58baa1 Drop broken DefaultCookie name validation, close #4999
Motivation:

DefaultCookie constructor performs a name validation that doesn’t match
RFC6265. Moreover, such validation is already performed in strict
encoders and decoders.

Modifications:

Drop DefaultCookie name validation, rely on encoders and decoders.

Result:

no more duplicate broken validation
2016-03-22 12:32:28 +01:00
Karas Lukáš
f5d5039bed Fix setBytes when source is read-only ByteBuffer and target is pooled buffer
Motivation:

The method setBytes creates temporary heap buffer when source buffer is read-only.
But this temporary buffer is not used correctly and may lead to data corruption.
This problem occurs when target buffer is pooled and temporary buffer
arrayOffset() is not zero.

Modifications:

Use correct arrayOffset when calling PlatformDependent.copyMemory.
Unit test was added to test this case.

Result:

Setting buffer content works correctly when target is pooled buffer and source
is read-only ByteBuffer.
2016-03-22 09:19:39 +01:00
Norman Maurer
64dc03a25d [maven-release-plugin] prepare for next development iteration 2016-03-21 10:34:26 +01:00
Norman Maurer
e444e8d7a6 [maven-release-plugin] prepare release netty-4.0.35.Final 2016-03-21 10:32:08 +01:00
Norman Maurer
d9d0e0c973 Ensure all pending SSL data is written before closing channel during handshake error.
Motivation:

We need to ensure we call ctx.flush() before closing the actual channel when an handshake failure took place. If we miss to do so we may not send all pending data to the remote peer which also include SSL alerts.

Modifications:

Ensure we call ctx.flush() before ctx.close() on a handshake error.

Result:

All pending data (including SSL alerts) are written to the remote peer on a handshake error.
2016-03-21 08:37:29 +01:00
Norman Maurer
77f57a1434 Ensure native memory is released when OpenSslServercontext constructor throws exception
Motivation:

We need to ensure we do all checks inside of the try / catch block so we free native memory that was allocated in the constructor of the super class in a timely manner.
Modifications:

Move all checks inside of the try block.

Result:

Correctly release native memory (and not depend on the finalizer) when a check in the constructors fails
2016-03-21 08:17:58 +01:00
Stephane Landelle
0310d79edf Add ! to allowed cookie value chars
Motivation:

! is missing from allowed cookie value chars, as per https://tools.ietf.org/html/rfc6265#section-4.1.1.
Issue was originally reported on Play!, see https://github.com/playframework/playframework/issues/4460#issuecomment-198177302.

Modifications:

Stick to RFC6265 ranges.

Result:

RFC6265 compliance, ! is supported
2016-03-18 16:59:39 +01:00
Norman Maurer
b6868077f3 Let getSoError() throw IOException as well
Motivation:

In commit acbca192bd we changed to have our native operations which either gall getsockopt or setsockopt throw IOExceptions (to be more specific we throw a ClosedChannelException in some cases). Unfortunally I missed to also do the same for getSoError() and missed to add throws IOException to the native methods.

Modifications:

- Correctly throw IOException from getSoError()
- Add throws IOException to native methods where it was missed.

Result:

Correct declaration of getSoError() and other native methods.

Conflicts:
	transport-native-epoll/src/main/java/io/netty/channel/epoll/AbstractEpollChannel.java
2016-03-17 20:11:30 +01:00
Norman Maurer
36f3999632 Fix calculation of PoolArena metrics after introducing a regression in 89da788fd2 2016-03-17 10:06:37 +01:00
Norman Maurer
0a87c98993 Support private key encrypted with empty password
Motivation:

A user may use a private key which is encrypted with an empty password. Because of this we should only handle a null password in a special way.

Modifications:

- Correctly handle private key that is encrypted with empty password.
- Make OpenSsl*Context implementions consistent in terms of initialization in the constructor.

Result:

Correctly support private key that is encrypted with empty password.
2016-03-17 09:07:41 +01:00
Norman Maurer
89da788fd2 Add proper synchronization when access metrics.
Motivation:

We also need to add synchronization when access fields to ensure we see the latest updates.

Modifications:

Add synchronization when read fields that are written concurrently.

Result:

Ensure correct visibility of updated.
2016-03-17 09:05:36 +01:00
Scott Mitchell
9b9b38bf89 EPOLL SO_LINGER=0 sends FIN+RST
Motivation:
If SO_LINGER is set to 0 the EPOLL transport will send a FIN followed by a RST. This is not consistent with the behavior of the NIO transport. This variation in behavior can cause protocol violations in streaming protocols (e.g. HTTP) where a FIN may be interpreted as a valid end to a data stream, but RST may be treated as the data is corrupted and should be discarded.

https://github.com/netty/netty/issues/4170 Claims the behavior of NIO always issues a shutdown when close occurs. I could not find any evidence of this in Netty's NIO transport nor in the JDK's SocketChannel.close() implementation.

Modifications:
- AbstractEpollChannel should be consistent with the NIO transport and not force a shutdown on every close
- FileDescriptor to keep state in a consistent manner with the JDK and not allow a shutdown after a close
- Unit tests for NIO and EPOLL to ensure consistent behavior

Result:
EPOLL is capable of sending just a RST to terminate a connection.
2016-03-16 22:35:31 -07:00
Tibor Csögör
4784f2761a trivial javadoc fixes
- fix the formatting of the diagram in ChannelFuture's javadoc
- update external link in AutobahnServer
- fix various spelling issues
2016-03-16 20:22:43 +01:00
Norman Maurer
f821698cec Remove double spacing
Motivation:

We had some double spacing in the methods which should be removed to keep things consistent.

Modifications:

Remove redundant spaces.

Result:

Cleaner / consistent coding style.
2016-03-16 10:28:31 +01:00
Norman Maurer
6b8c87997c Add final keyword which was missing in 47b598e6ce
Motivation:

The two fields should have final keyword.

Modifications:

Add final keyword

Result:

Cleaner code.
2016-03-16 10:24:50 +01:00
buchgr
a42bf5495e Fix wrong use of assertTrue in unit test.
Motivation:

My previous commit b88a980482 introduced a flawed unit test,
that executes an assertion in a different thread than the test thread.
If this assertion fails, the test doesn't fail.

Modifications:

Replace the assertion by a proper workaround.

Result:

More correct unit test
2016-03-15 16:02:02 +01:00
Norman Maurer
1090d7200d ChannelConfig operations should wrap ClosedChannelException if Channel was closed before.
Motivation:

To be consistent with the JDK we should ensure our native methods throw a ClosedChannelException if the Channel was previously closed. This will then be wrapped in a ChannelException as usual. For all other errors we continue to just throw a ChannelException directly.

Modifications:

Ensure getsockopt and setsockopt will throw a ClosedChannelException if the channel was closed before, on other errors we throw a ChannelException as before diretly.

Result:

Consistent with the NIO Channel implementations.
2016-03-15 14:46:57 +01:00
buchgr
dcf553f1aa Change arena to thread cache mapping algorithm to be closer to ideal.
Motivation:
Circular assignment of arenas to thread caches can lead to less than optimal
mappings in cases where threads are (frequently) shutdown and started.

Example Scenario:
There are a total of 2 arenas. The first two threads performing an allocation
would lead to the following mapping:

Thread 0 -> Arena 0
Thread 1 -> Arena 1

Now, assume Thread 1 is shut down and another Thread 2 is started. The current
circular assignment algorithm would lead to the following mapping:

Thread 0 -> Arena 0
Thread 2 -> Arena 0

Ideally, we want Thread 2 to use Arena 1 though.

Presumably, this is not much of an issue for most Netty applications that do all
the allocations inside the eventloop, as eventloop threads are seldomly shut down
and restarted. However, applications that only use the netty-buffer package
or implement their own threading model outside the eventloop might suffer from
increased contention. For example, gRPC Java when using the blocking stub
performs some allocations outside the eventloop and within its own thread pool
that is dynamically sized depending on system load.

Modifications:

Implement a linear scan algorithm that assigns a new thread cache to the arena
that currently backs the fewest thread caches.

Result:

Closer to ideal mappings between thread caches and arenas. In order to always
get an ideal mapping, we would have to re-balance the mapping whenever a thread
dies. However, that's difficult because of deallocation.
2016-03-15 14:22:57 +01:00
johnou
b9bf11d71a Adding support for tcnative fedora flavour in uber jar
Motivation:

We want to allow the use of an uber jar that contains shared dynamic libraries for all platforms (including fedora).

Modifications:

Modified OpenSsl to try and load the fedora library if the OS is Linux and the platform specified library fails before using the default lib.

Result:

True uber support.
2016-03-15 13:56:21 +01:00