Go to file
Trustin Lee 32efba34d8 Initial implementation of the Streaming API
This pull request provides a framework for exchanging a very large
stream between handlers, typically between a decoder and an inbound
handler (or between a handler that writes a message and an encoder that
encodes that message).

For example, an HTTP decoder, previously, generates multiple
micro-messages to decode an HTTP message (i.e. HttpRequest +
HttpChunks). With the streaming API, The HTTP decoder can simply
generate a single HTTP message whose content is a Stream. And then the
inbound handler can consume the Stream via the buffer you created when
you begin to read the stream. If you create a buffer whose capacity is
bounded, you can handle a very large stream without allocating a lot of
memory. If you just want to wait until the whole content is ready, you
can also do that with an unbounded buffer.

The streaming API also supports a limited form of communication between
a producer (i.e. decoder) and a consumer. A producer can abort the
stream if the stream is not valid anymore. A consumer can choose to
reject or discard the stream, where rejection is for unrecoverable
failure and discard is for recoverable failure.

P.S. Special thanks to @jpinner for the initial input.
2013-03-11 08:57:17 +09:00
all [maven-release-plugin] prepare for next development iteration 2013-02-26 16:55:07 -08:00
buffer Initial implementation of the Streaming API 2013-03-11 08:57:17 +09:00
codec [#1131] Codecs must not cache next buffer during processing 2013-03-08 15:38:17 +01:00
codec-http Allow to specify the used buffer type for ChannelInboundByteBufHandler and ChannelOutboundByteBufHandler by configuration. As default it tries to use a direct ByteBuf 2013-03-08 08:20:46 +01:00
codec-socks [maven-release-plugin] prepare for next development iteration 2013-02-26 16:55:07 -08:00
common Fix a bug where TypeParameterMatcher raises ClassCastException when an instance with raw type parameter is given 2013-03-09 09:19:34 +09:00
example Allow to specify the used buffer type for ChannelInboundByteBufHandler and ChannelOutboundByteBufHandler by configuration. As default it tries to use a direct ByteBuf 2013-03-08 08:20:46 +01:00
handler Allow to specify the used buffer type for ChannelInboundByteBufHandler and ChannelOutboundByteBufHandler by configuration. As default it tries to use a direct ByteBuf 2013-03-08 08:20:46 +01:00
license Add back jzlib license file and notice 2013-02-21 14:00:59 -08:00
microbench Change ByteBufAllocator.buffer() to allocate a direct buffer only when the platform can handle a direct buffer reliably 2013-03-05 17:55:24 +09:00
tarball [maven-release-plugin] prepare for next development iteration 2013-02-26 16:55:07 -08:00
testsuite Allow to specify the used buffer type for ChannelInboundByteBufHandler and ChannelOutboundByteBufHandler by configuration. As default it tries to use a direct ByteBuf 2013-03-08 08:20:46 +01:00
testsuite-osgi [maven-release-plugin] prepare for next development iteration 2013-02-26 16:55:07 -08:00
transport Javadocs cleanup / added 2013-03-10 21:07:19 +01:00
transport-rxtx Allow to specify the used buffer type for ChannelInboundByteBufHandler and ChannelOutboundByteBufHandler by configuration. As default it tries to use a direct ByteBuf 2013-03-08 08:20:46 +01:00
transport-sctp Allow to specify the used buffer type for ChannelInboundByteBufHandler and ChannelOutboundByteBufHandler by configuration. As default it tries to use a direct ByteBuf 2013-03-08 08:20:46 +01:00
transport-udt Allow to specify the used buffer type for ChannelInboundByteBufHandler and ChannelOutboundByteBufHandler by configuration. As default it tries to use a direct ByteBuf 2013-03-08 08:20:46 +01:00
.fbfilter.xml Update license headers 2012-06-04 13:31:44 -07:00
.fbprefs Updated Find Bugs configuration 2009-03-04 10:33:09 +00:00
.gitignore ignore .idea/ folder 2012-01-16 16:01:00 +08:00
.travis.yml Travis CI configuration 2013-03-11 08:47:12 +09:00
LICENSE.txt Relicensed to Apache License v2 2009-08-28 07:15:49 +00:00
NOTICE.txt Add back jzlib license file and notice 2013-02-21 14:00:59 -08:00
pom.xml [maven-release-plugin] prepare for next development iteration 2013-02-26 16:55:07 -08:00
README.md Fix broken url 2013-02-26 16:29:24 -08: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