andreacavalli/netty5
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Fix Javadoc issues. Replace Upstream with Inbound and Downstream with Outbound.

Browse Source
This commit is contained in:
George Cao 2013-04-02 13:56:34 +08:00 committed by Trustin Lee
parent 2e3b8f13ea
commit 436380c41e
1 changed files with 13 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

26
transport/src/main/java/io/netty/channel/ChannelPipeline.java
View File

@ -97,18 +97,18 @@ import java.util.NoSuchElementException;
* | Netty Internal I/O Threads (Transport Implementation) |
* +----------------------------------------------------------------------+
* </pre>
* An upstream event is handled by the upstream handlers in the bottom-up
* direction as shown on the left side of the diagram. An upstream handler
* An inbound event is handled by the inbound handlers in the bottom-up
* direction as shown on the left side of the diagram. An inbound handler
* usually handles the inbound data generated by the I/O thread on the bottom
* of the diagram. The inbound data is often read from a remote peer via the
* actual input operation such as {@link InputStream#read(byte[])}.
* If an upstream event goes beyond the top upstream handler, it is discarded
* If an inbound event goes beyond the top inbound handler, it is discarded
* silently.
* <p>
* A downstream event is handled by the downstream handler in the top-down
* direction as shown on the right side of the diagram. A downstream handler
* A outbound event is handled by the outbound handler in the top-down
* direction as shown on the right side of the diagram. A outbound handler
* usually generates or transforms the outbound traffic such as write requests.
* If a downstream event goes beyond the bottom downstream handler, it is
* If a outbound event goes beyond the bottom outbound handler, it is
* handled by an I/O thread associated with the {@link Channel}. The I/O thread
* often performs the actual output operation such as {@link OutputStream#write(byte[])}.
* <p>
@ -121,23 +121,23 @@ import java.util.NoSuchElementException;
* p.addLast("4", new OutboundHandlerB());
* p.addLast("5", new InboundOutboundHandlerX());
* </pre>
* In the example above, the class whose name starts with {@code Upstream} means
* it is an upstream handler. The class whose name starts with
* {@code Downstream} means it is a downstream handler.
* In the example above, the class whose name starts with {@code Inbound} means
* it is an inbound handler. The class whose name starts with
* {@code Outbound} means it is a outbound handler.
* <p>
* In the given example configuration, the handler evaluation order is 1, 2, 3,
* 4, 5 when an event goes upstream. When an event goes downstream, the order
* 4, 5 when an event goes inbound. When an event goes outbound, the order
* is 5, 4, 3, 2, 1. On top of this principle, {@link ChannelPipeline} skips
* the evaluation of certain handlers to shorten the stack depth:
* <ul>
* <li>3 and 4 don't implement {@link ChannelInboundHandler}, and therefore the
* actual evaluation order of an upstream event will be: 1, 2, and 5.</li>
* actual evaluation order of an inbound event will be: 1, 2, and 5.</li>
* <li>1, 2, and 5 don't implement {@link ChannelOutboundHandler}, and
* therefore the actual evaluation order of a downstream event will be:
* therefore the actual evaluation order of a outbound event will be:
* 4 and 3.</li>
* <li>If 5 implements both
* {@link ChannelInboundHandler} and {@link ChannelOutboundHandler}, the
* evaluation order of an upstream and a downstream event could be 125 and
* evaluation order of an inbound and a outbound event could be 125 and
* 543 respectively.</li>
* </ul>
*