c8fb2a84c5
Motivation: Doc of ChannelGroup says, that it can be used to manage server and child channels at once. However, in DefaultChannelGroup, there is a race condition. When a server channel accepts a child, it schedules its registration on an event loop, which takes some time. If the ChannelGroup, which is supposed to close server and child channels at once, is closed after the child channel has been scheduled for registration and before this registration actually happens, this child channel is not closed and remains connected. This could lead to connection leaks. Modifications: To fix this, the DefaultChannelGroup is changed to has a closed flag. This flag is set to true, just before the close() method is actually closing channels. The add() method checks after adding a new channel, if this flag has been set to true. If yes, the new channel is closed. If not, we have the guarantee, that this channel will be closed by the ChannelGroup, because setting the closed flag to true happens-before closing any channels. This behaviour can be activated by two new constructors. The old constructors are still there and behave like before. Therefore, no existing code should be affected directly. Result: If activating this feature, the DefaultChannelGroup can be used, for managing server and child channels at once. But this activating this feature means also, that a ChannelGroup cannot be reused after calling close(). |
||
|---|---|---|
| all | ||
| buffer | ||
| codec | ||
| codec-dns | ||
| codec-haproxy | ||
| codec-http | ||
| codec-http2 | ||
| codec-memcache | ||
| codec-mqtt | ||
| codec-socks | ||
| codec-stomp | ||
| codec-xml | ||
| common | ||
| example | ||
| handler | ||
| handler-proxy | ||
| license | ||
| microbench | ||
| resolver | ||
| resolver-dns | ||
| tarball | ||
| testsuite | ||
| testsuite-osgi | ||
| 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.