de0c416de0
Motivation: The outbound flow controller currently has to walk the entire tree each time to calculate the total available data for each subtree. For better performance we should maintain a running total for each subtree as we queue/write frames. Modifications: I've modified the DefaultHttp2OutboundFlowController to manage the state of "priorityData" at each node in the priority tree, which is essentially the total writable data for all streams in that subtree. These totals do not take into account the connection window, as that is applied when splitting the data across the streams at each level in the tree. The flow controller now sorts the children of a node by the product of their data (for the subtree) and its weight. This is used since in certain cases the algorithm might prefer nodes that appear later in the list. Sorting helps keep nodes with similar characteristics (e.g. a lot of data and a high priority) with similar output. To help clean things up, I'm storing a FlowState for the root node as well, which maintains the runnning total of the currently writable data for all stream. Another item of cleanup is that I created a GarbageCollector innerclass within the outbound flow controller. This keeps all of the garbage collection code in one place, away from the flow control code. Also added some more unit tests for the flow controller. Result: The outbound flow controller is a bit cleaner and perhaps a bit more fair when distributing outbound data across streams. |
||
|---|---|---|
| all | ||
| buffer | ||
| codec | ||
| codec-http | ||
| codec-http2 | ||
| codec-memcache | ||
| codec-socks | ||
| common | ||
| example | ||
| handler | ||
| license | ||
| microbench | ||
| tarball | ||
| testsuite | ||
| transport | ||
| transport-native-epoll | ||
| transport-rxtx | ||
| transport-sctp | ||
| transport-udt | ||
| .fbfilter.xml | ||
| .fbprefs | ||
| .gitignore | ||
| .travis.yml | ||
| CONTRIBUTING.md | ||
| LICENSE.txt | ||
| NOTICE.txt | ||
| pom.xml | ||
| README.md | ||
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
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.