Trouble understanding the handler pipeline

[Utkarsh Srivastava]

Yes, much better now, thanks!

On Wed, Apr 8, 2009 at 1:41 AM, Trustin Lee <tlee at redhat.com> wrote:

> 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
> >
> >
>
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/netty-users/attachments/20090410/5d096a0f/attachment.html