diff --git a/src/main/java/org/jboss/netty/channel/ChannelPipeline.java b/src/main/java/org/jboss/netty/channel/ChannelPipeline.java index c6a2cadcf8..e01768d092 100644 --- a/src/main/java/org/jboss/netty/channel/ChannelPipeline.java +++ b/src/main/java/org/jboss/netty/channel/ChannelPipeline.java @@ -98,6 +98,35 @@ import org.jboss.netty.handler.ssl.SslHandler; * to the last upstream handler (i.e. to the next) and a downstream event * flows from the last downstream handler to the first downstream handler * (i.e. to the previous). + *

+ * For example, let us assume that we created the following pipeline: + *

+ * ChannelPipeline p = Channels.pipeline();
+ * p.addLast("1", new UpstreamHandlerA());
+ * p.addLast("2", new UpstreamHandlerB());
+ *.p.addLast("3", new DownstreamHandlerA());
+ *.p.addLast("4", new DownstreamHandlerB());
+ * p.addLast("5", new UpstreamHandlerX());
+ * 
+ * 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 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 + * is 5, 4, 3, 2, 1. On top of this principle, {@link ChannelPipeline} skips + * the evaluation of certain handlers to shorten the stack depth: + *

* *

Building a pipeline

*