Go to file
Scott Mitchell b712480b56 HttpObjectAggregator Potential Leak
Motivation:
HttpObjectAggregator has a potential to leak if a new message is received before the existing message has completed, and if a HttpContent is received but maxContentLength has been exceeded, or the content length is too long.

Modifications:
- Make the HttpObjectAggregator more robust to leaks
- Remove the tooLongFrameFound member variable

Result:
More robust HttpObjectAggregator with less chance of leaks
2016-09-13 18:55:04 -07:00
all [maven-release-plugin] prepare for next development iteration 2016-08-26 08:36:54 +02:00
buffer Share code between retain(...) and release(...) implementations. 2016-09-02 21:56:22 +02:00
codec [maven-release-plugin] prepare for next development iteration 2016-08-26 08:36:54 +02:00
codec-haproxy [maven-release-plugin] prepare for next development iteration 2016-08-26 08:36:54 +02:00
codec-http HttpObjectAggregator Potential Leak 2016-09-13 18:55:04 -07:00
codec-socks [maven-release-plugin] prepare for next development iteration 2016-08-26 08:36:54 +02:00
common Log less confusing message when try to load native library 2016-09-13 17:16:02 -07:00
example Remove OSGi import of JCTools since it is shaded. 2016-09-13 14:22:29 -07:00
handler Only set lastReadTime if an read actually happened before in IdleStateHandler. 2016-09-13 16:57:37 -07:00
license Let PoolThreadCache work even if allocation and deallocation Thread are different 2015-05-27 14:35:22 +02:00
microbench [maven-release-plugin] prepare for next development iteration 2016-08-26 08:36:54 +02:00
tarball [maven-release-plugin] prepare for next development iteration 2016-08-26 08:36:54 +02:00
testsuite Fix compile error introduced by bac0d4c0e0 2016-09-01 08:39:52 +02:00
testsuite-osgi [maven-release-plugin] prepare for next development iteration 2016-08-26 08:36:54 +02:00
transport Fix javadoc 2016-09-12 06:43:36 -07:00
transport-native-epoll Correct throw ClosedChannelException when attempt to call shutdown*(...) on closed EpollSocketChannel. 2016-09-01 08:16:09 +02:00
transport-rxtx [maven-release-plugin] prepare for next development iteration 2016-08-26 08:36:54 +02:00
transport-sctp [maven-release-plugin] prepare for next development iteration 2016-08-26 08:36:54 +02:00
transport-udt [maven-release-plugin] prepare for next development iteration 2016-08-26 08:36:54 +02: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:53:28 +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: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 Remove OSGi import of JCTools since it is shaded. 2016-09-13 14:22:29 -07:00
README.md Updating Branches to look section to match the current branching structure of the project 2016-03-10 22:09:30 +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

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.