Yes, thanks, its clear now. I think this deserves a mention in the docs, otherwise its too mysterious.<br><br>Utkarsh<br><br><div class="gmail_quote">On Tue, Mar 10, 2009 at 3:11 PM, Trustin Lee <span dir="ltr">&lt;<a href="mailto:tlee@redhat.com">tlee@redhat.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div></div><div class="h5">On Wed, Mar 11, 2009 at 6:30 AM, Utkarsh Srivastava &lt;<a href="mailto:utkarsh@gmail.com">utkarsh@gmail.com</a>&gt; wrote:<br>

&gt; Hi,<br>
&gt;<br>
&gt; I am a day old to netty and still finding my way around. Looks like a really<br>
&gt; slick framework!<br>
&gt;<br>
&gt; I am having a little trouble understanding the handler pipeline (yes, I have<br>
&gt; read the api docs for ChannelPipeline, ChannelHandler and ChannelEvent). To<br>
&gt; take a concrete example, the server pipeline in the example time server has<br>
&gt; the following pipeline:<br>
&gt;<br>
&gt;         ChannelPipeline p = pipeline();<br>
&gt;         1. p.addLast(&quot;frameDecoder&quot;, new<br>
&gt; LengthFieldBasedFrameDecoder(1048576, 0, 4, 0, 4));<br>
&gt;         2. p.addLast(&quot;protobufDecoder&quot;, new<br>
&gt; ProtobufDecoder(LocalTimeProtocol.Locations.getDefaultInstance()));<br>
&gt;<br>
&gt;         3. p.addLast(&quot;frameEncoder&quot;, new LengthFieldPrepender(4));<br>
&gt;         4. p.addLast(&quot;protobufEncoder&quot;, new ProtobufEncoder());<br>
&gt;<br>
&gt;         5. p.addLast(&quot;handler&quot;, new LocalTimeServerHandler());<br>
&gt;         return p;<br>
&gt;<br>
&gt; For a given request, handlers are executed in the order 1,2,5,4,3, right?<br>
&gt; Thats the only order that makes sense.<br>
&gt;<br>
&gt; But thats totally different from the order they are added to the pipeline in<br>
&gt; the code.<br>
<br>
</div></div>That&#39;s a good question.  When an event goes upstream, the order is 1,<br>
2, 3, 4, 5.  When an event goes downstream, the order is 5, 4, 3, 2,<br>
1.  However, ChannelPipline does some trick to shorten the stack<br>
depth.<br>
<br>
3 and 4 don&#39;t implement ChannelUpstreamHandler, and therefore the<br>
actual evaluation order of an upstream event will be: 1, 2, and 5.<br>
<br>
1, 2, and 5 don&#39;t implement ChannelDownstreamHandler, and therefore<br>
the actual evaluation order of a downstream event will be: 4 and 3<br>
<br>
If 5 extends SimpleChannelHandler, it means 5 implements both<br>
ChannelUpstreamHandler and ChannelDownstreamHandler.  Therefore the<br>
evaluation order for upstream and downstream events will be 125 and<br>
543.<br>
<br>
Sounds clear? :)<br>
<br>
HTH,<br>
Trustin<br>
<br>
_______________________________________________<br>
netty-users mailing list<br>
<a href="mailto:netty-users@lists.jboss.org">netty-users@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/netty-users" target="_blank">https://lists.jboss.org/mailman/listinfo/netty-users</a><br>
</blockquote></div><br>