Added a shutdown() method on ChannelFactory, Boss, Worker, BossPool, WorkerPool and Bootstrap which can be used to just shutdown the instance and so release all internal created resources. This method is also called when releaseExternalResources() which will also release external created resources like Executors.
This commit also fixes the problem that the Worker/Boss Thread will never be released if you use an Executor (no ExecutorService).
This commit adds rebuildSelector(s) method to Boss, BossPool, Worker, and WorkerPool. A user can call rebuildSelector(s) method to initiate the workaround for the infamous epoll 100% CPU bug in Linux based on his or her observations rather than potentially incorrect automatic initiation of the workaround.
Previously, setInterestOps() were executed by a caller thread, which made re-registration of SelectionKeys unsafe. This commit also ensures setInterestOps() is always executed by an I/O thread. With this change, we don't need NioProviderMetadata anymore.
* Beside this allow to set a ThreadNameDeterminer per BossPool and WorkerPool. This allows to have different determiner instances in the same JVM.
This fixes#771.
* With the possiblity to share BossPools it is even easier to limit the Thread counts even if you need to create many ChannelFactory instances. So this gives a lot of flexibility.
(See #768)
Once too long object is received, CompatibleMarshallingDecoder has to
discard all input from now on, just like MarshallingDecoder does.
Otherwise, the decoder will raise more exceptions because the decoder
has no idea anymore where the object starts.
Before this fix, SerialThreadLocalCompatibleMarshallingDecoderTest
logged many additional exceptions raised by the decoder after test is
finished.
Using DelimiterBasedFrameDecoder with Delimiters.lineDelimiter() has
quadratic performance in the size of the input buffer. Needless to
say, the performance degrades pretty quickly as the size of the buffer
increases. Larger MTUs or loopback connections can make it so bad that
it appears that the code is "busy waiting", when in fact it's spending
almost 100% of the CPU time in DelimiterBasedFrameDecoder.indexOf().
Add a new LineBasedFrameDecoder that decodes line-delimited frames
in O(n) instead of DelimiterBasedFrameDecoder's O(n^2) implementation.
In OpenTSDB's telnet-style protocol decoder this resulted in throughput
increases of an order of magnitude.
Change DelimiterBasedFrameDecoder to automatically detect when the
frames are delimited by line endings, and automatically switch to
using LineBasedFrameDecoder under the hood. This means that all Netty
applications out there that using the combo DelimiterBasedFrameDecoder
with Delimiters.lineDelimiter() will automatically benefit from the
better performance of LineBasedFrameDecoder, without requiring a code
change.
