Go to file
Scott Mitchell 237a4da1b7 Shutting down the outbound side of the channel should not accept future writes
Motivation:
Implementations of DuplexChannel delegate the shutdownOutput to the underlying transport, but do not take any action on the ChannelOutboundBuffer. In the event of a write failure due to the underlying transport failing and application may attempt to shutdown the output and allow the read side the transport to finish and detect the close. However this may result in an issue where writes are failed, this generates a writability change, we continue to write more data, and this may lead to another writability change, and this loop may continue. Shutting down the output should fail all pending writes and not allow any future writes to avoid this scenario.

Modifications:
- Implementations of DuplexChannel should null out the ChannelOutboundBuffer and fail all pending writes

Result:
More controlled sequencing for shutting down the output side of a channel.
2017-08-04 10:59:57 -07:00
.github Use GitHub Issue/PR Template Feature 2016-12-07 11:40:26 -08:00
all [maven-release-plugin] prepare for next development iteration 2017-08-02 12:55:10 +00:00
bom [maven-release-plugin] prepare for next development iteration 2017-08-02 12:55:10 +00:00
buffer [maven-release-plugin] prepare for next development iteration 2017-08-02 12:55:10 +00:00
codec Only call ctx.fireChannelReadComplete() if ByteToMessageDecoder decoded at least one message. 2017-08-04 10:54:56 +02:00
codec-dns [maven-release-plugin] prepare for next development iteration 2017-08-02 12:55:10 +00:00
codec-haproxy [maven-release-plugin] prepare for next development iteration 2017-08-02 12:55:10 +00:00
codec-http Only call ctx.fireChannelReadComplete() if ByteToMessageDecoder decoded at least one message. 2017-08-04 10:54:56 +02:00
codec-http2 First call channelReadComplete(...) before flush(...) for better performance 2017-08-04 11:55:35 +02:00
codec-memcache [maven-release-plugin] prepare for next development iteration 2017-08-02 12:55:10 +00:00
codec-mqtt [maven-release-plugin] prepare for next development iteration 2017-08-02 12:55:10 +00:00
codec-redis [maven-release-plugin] prepare for next development iteration 2017-08-02 12:55:10 +00:00
codec-smtp [maven-release-plugin] prepare for next development iteration 2017-08-02 12:55:10 +00:00
codec-socks [maven-release-plugin] prepare for next development iteration 2017-08-02 12:55:10 +00:00
codec-stomp [maven-release-plugin] prepare for next development iteration 2017-08-02 12:55:10 +00:00
codec-xml [maven-release-plugin] prepare for next development iteration 2017-08-02 12:55:10 +00:00
common Remove io.netty.packagePrefix system property 2017-08-04 10:53:29 +02:00
dev-tools [maven-release-plugin] prepare for next development iteration 2017-08-02 12:55:10 +00:00
example [maven-release-plugin] prepare for next development iteration 2017-08-02 12:55:10 +00:00
handler Only call ctx.fireChannelReadComplete() if ByteToMessageDecoder decoded at least one message. 2017-08-04 10:54:56 +02:00
handler-proxy [maven-release-plugin] prepare for next development iteration 2017-08-02 12:55:10 +00:00
license Remove reference to akka code and ArrayDeque which is not part of netty anymore 2017-03-07 21:30:51 +01:00
microbench [maven-release-plugin] prepare for next development iteration 2017-08-02 12:55:10 +00:00
resolver [maven-release-plugin] prepare for next development iteration 2017-08-02 12:55:10 +00:00
resolver-dns [maven-release-plugin] prepare for next development iteration 2017-08-02 12:55:10 +00:00
tarball [maven-release-plugin] prepare for next development iteration 2017-08-02 12:55:10 +00:00
testsuite Shutting down the outbound side of the channel should not accept future writes 2017-08-04 10:59:57 -07:00
testsuite-autobahn [maven-release-plugin] prepare for next development iteration 2017-08-02 12:55:10 +00:00
testsuite-osgi [maven-release-plugin] prepare for next development iteration 2017-08-02 12:55:10 +00:00
transport Shutting down the outbound side of the channel should not accept future writes 2017-08-04 10:59:57 -07:00
transport-native-epoll Shutting down the outbound side of the channel should not accept future writes 2017-08-04 10:59:57 -07:00
transport-native-kqueue Shutting down the outbound side of the channel should not accept future writes 2017-08-04 10:59:57 -07:00
transport-native-unix-common Correctly handle connect/disconnect in EpollDatagramChannel / KQueueDatagramChannel 2017-08-04 09:22:53 +02:00
transport-native-unix-common-tests [maven-release-plugin] prepare for next development iteration 2017-08-02 12:55:10 +00:00
transport-rxtx [maven-release-plugin] prepare for next development iteration 2017-08-02 12:55:10 +00:00
transport-sctp [maven-release-plugin] prepare for next development iteration 2017-08-02 12:55:10 +00:00
transport-udt [maven-release-plugin] prepare for next development iteration 2017-08-02 12:55:10 +00:00
.fbprefs Updated Find Bugs configuration 2009-03-04 10:33:09 +00:00
.gitignore Use shaded dependency on JCTools instead of copy and paste 2016-06-10 13:19:45 +02: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:13:58 +09:00
LICENSE.txt Relicensed to Apache License v2 2009-08-28 07:15:49 +00:00
NOTICE.txt Remove reference to akka code and ArrayDeque which is not part of netty anymore 2017-03-07 21:30:51 +01:00
pom.xml Upgrading to Conscrypt 1.0.0.RC9. (#7044) 2017-08-03 14:21:32 -07:00
README.md Updating Branches to look section to match the current branching structure of the project 2016-03-10 22:08:01 +01:00
run-example.sh Add UptimeServer and adjust UptimeClient's code style. 2017-04-28 07:41:07 +02: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

Development of all 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.