Go to file
Norman Maurer ba381f1a27 Ensure ChannelHandler.handlerAdded(...) is always called as first method of the handler
Motivation:

If a user adds a ChannelHandler from outside the EventLoop it is possible to get into the situation that handlerAdded(...) is scheduled on the EventLoop and so called after another methods of the ChannelHandler as the EventLoop may already be executing on this point in time.

Modification:

- Ensure we always check if the handlerAdded(...) method was called already and if not add the currently needed call to the EventLoop so it will be picked up after handlerAdded(...) was called. This works as if the handler is added to the ChannelPipeline from outside the EventLoop the actual handlerAdded(...) operation is scheduled on the EventLoop.
- Some cleanup in the DefaultChannelPipeline

Result:

Correctly order of method executions of ChannelHandler.
2016-01-28 14:40:51 +01:00
all Fix version 2015-11-24 21:24:22 +01:00
buffer [#4017] Implement proper resource leak detection for CompositeByteBuf 2016-01-18 10:50:12 +01:00
codec Change 64 to 63 in Snappy.decodeLiteral 2016-01-21 09:59:44 +01:00
codec-haproxy Fix version 2015-11-24 21:24:22 +01:00
codec-http Set default CONTENT_TYPE when it is absent in multipart request body 2016-01-26 10:17:07 +01:00
codec-socks Fix version 2015-11-24 21:24:22 +01:00
common PlatformDependent static initialization ExceptionInInitializerError 2016-01-20 06:04:32 -08:00
example Use jetty-alpn-agent to simplify pom.xml 2016-01-04 20:40:46 +01:00
handler SslHandler should call beginHanshake once for the initial handshake 2016-01-28 13:27:45 +01:00
license Let PoolThreadCache work even if allocation and deallocation Thread are different 2015-05-27 14:35:22 +02:00
microbench Fix version 2015-11-24 21:24:22 +01:00
tarball Fix version 2015-11-24 21:24:22 +01:00
testsuite Fix version 2015-11-24 21:24:22 +01:00
testsuite-osgi Fix version 2015-11-24 21:24:22 +01:00
transport Ensure ChannelHandler.handlerAdded(...) is always called as first method of the handler 2016-01-28 14:40:51 +01:00
transport-native-epoll Correctly handle wildcard address when bind to socket and using native transport 2016-01-28 14:07:45 +01:00
transport-rxtx Fix version 2015-11-24 21:24:22 +01:00
transport-sctp Improve SctpMessage.hashCode method 2016-01-05 20:45:43 +01:00
transport-udt Fix version 2015-11-24 21:24:22 +01:00
.fbprefs Updated Find Bugs configuration 2009-03-04 10:33:09 +00:00
.gitignore Add JVM crash logs to .gitignore 2014-05-18 21:37:12 +09:00
.travis.yml Travis CI branch whitelisting 2013-03-11 09:55:43 +09:00
CONTRIBUTING.md Move the pull request guide to the developer guide 2014-03-12 13:18:14 +09:00
LICENSE.txt Relicensed to Apache License v2 2009-08-28 07:15:49 +00:00
NOTICE.txt Let PoolThreadCache work even if allocation and deallocation Thread are different 2015-05-27 14:35:22 +02:00
pom.xml Clear disabled SSL protocols before enabling provided SSL protocols 2016-01-22 17:33:14 +01:00
README.md Fix the 'branches to look' section 2015-10-27 13:58:06 +01:00
run-example.sh Add logLevel property to enable different log levels for the examples. 2014-11-21 10:48:13 +09:00

Netty Project

Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients.

How to build

For the detailed information about building and developing Netty, please visit the developer guide. This page only gives very basic information.

You require the following to build Netty:

Note that this is build-time requirement. JDK 5 (for 3.x) or 6 (for 4.0+) is enough to run your Netty-based application.

Branches to look

The 'master' branch is where the development of the latest major version lives on. The development of all other versions takes place in each branch whose name is identical to <majorVersion>.<minorVersion>. For example, the development of 3.9 and 4.0 resides in the branch '3.9' and the branch '4.0' respectively.