Trouble understanding the handler pipeline

Trustin Lee tlee at redhat.com
Wed Apr 8 04:41:29 EDT 2009


I've just updated the Javadoc of ChannelPipeline.  I hope you like
this improvement. :)

— Trustin Lee, http://gleamynode.net/

On Wed, Mar 11, 2009 at 8:36 AM, Utkarsh Srivastava <utkarsh at gmail.com> wrote:
> Yes, thanks, its clear now. I think this deserves a mention in the docs,
> otherwise its too mysterious.
>
> Utkarsh
>
> On Tue, Mar 10, 2009 at 3:11 PM, Trustin Lee <tlee at redhat.com> wrote:
>>
>> 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
>>
>> _______________________________________________
>> netty-users mailing list
>> netty-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/netty-users
>
>
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users
>
>




More information about the netty-users mailing list