Trouble understanding the handler pipeline

[Trustin Lee]

On Wed, Mar 11, 2009 at 6:30 AM, Utkarsh Srivastava <utkarsh at gmail.com> wrote:
> Hi,
>
> I am a day old to netty and still finding my way around. Looks like a really
> slick framework!
>
> I am having a little trouble understanding the handler pipeline (yes, I have
> read the api docs for ChannelPipeline, ChannelHandler and ChannelEvent). To
> take a concrete example, the server pipeline in the example time server has
> the following pipeline:
>
>         ChannelPipeline p = pipeline();
>         1. p.addLast("frameDecoder", new
> LengthFieldBasedFrameDecoder(1048576, 0, 4, 0, 4));
>         2. p.addLast("protobufDecoder", new
> ProtobufDecoder(LocalTimeProtocol.Locations.getDefaultInstance()));
>
>         3. p.addLast("frameEncoder", new LengthFieldPrepender(4));
>         4. p.addLast("protobufEncoder", new ProtobufEncoder());
>
>         5. p.addLast("handler", new LocalTimeServerHandler());
>         return p;
>
> For a given request, handlers are executed in the order 1,2,5,4,3, right?
> Thats the only order that makes sense.
>
> But thats totally different from the order they are added to the pipeline in
> the code.

That's a good question.  When an event goes upstream, the order is 1,
2, 3, 4, 5.  When an event goes downstream, the order is 5, 4, 3, 2,
1.  However, ChannelPipline does some trick to shorten the stack
depth.

3 and 4 don't implement ChannelUpstreamHandler, and therefore the
actual evaluation order of an upstream event will be: 1, 2, and 5.

1, 2, and 5 don't implement ChannelDownstreamHandler, and therefore
the actual evaluation order of a downstream event will be: 4 and 3

If 5 extends SimpleChannelHandler, it means 5 implements both
ChannelUpstreamHandler and ChannelDownstreamHandler.  Therefore the
evaluation order for upstream and downstream events will be 125 and
543.

Sounds clear? :)

HTH,
Trustin