46576fd2ff
Related: #3156 Motivation: Let's say we have a channel with the following pipeline configuration: HEAD --> [E1] H1 --> [E2] H2 --> TAIL when the channel is deregistered, the channelUnregistered() methods of H1 and H2 will be invoked from the executor thread of E1 and E2 respectively. To ensure that the channelUnregistered() methods are invoked from the correct thread, new one-time tasks will be created accordingly and be scheduled via Executor.execute(Runnable). As soon as the one-time tasks are scheduled, DefaultChannelPipeline.fireChannelUnregistered() will start to remove all handlers from the pipeline via teardownAll(). This process is performed in reversed order of event propagation. i.e. H2 is removed first, and then H1 is removed. If the channelUnregistered() event has been passed to H2 before H2 is removed, a user does not see any problem. If H2 has been removed before channelUnregistered() event is passed to H2, a user will often see the following confusing warning message: An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception. Modifications: To ensure that the handlers are removed *after* all events are propagated, traverse the pipeline in ascending order before performing the actual removal. Result: A user does not get the confusing warning message anymore. |
||
|---|---|---|
| all | ||
| buffer | ||
| codec | ||
| codec-dns | ||
| codec-haproxy | ||
| codec-http | ||
| codec-memcache | ||
| codec-mqtt | ||
| codec-socks | ||
| codec-stomp | ||
| common | ||
| example | ||
| handler | ||
| handler-proxy | ||
| license | ||
| microbench | ||
| resolver | ||
| resolver-dns | ||
| tarball | ||
| testsuite | ||
| transport | ||
| transport-native-epoll | ||
| transport-rxtx | ||
| transport-sctp | ||
| transport-udt | ||
| .fbprefs | ||
| .gitignore | ||
| .travis.yml | ||
| CONTRIBUTING.md | ||
| LICENSE.txt | ||
| NOTICE.txt | ||
| pom.xml | ||
| README.md | ||
| run-example.sh | ||
Netty Project
Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients.
Links
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:
- Latest stable Oracle JDK 7
- Latest stable Apache Maven
- If you are on Linux, you need additional development packages installed on your system, because you'll build the native transport.
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.