I was wondering which option would be the best for my app, SEDA or not?<div><br></div><div>I have a server that will need to handle a big load, and the average execution time of each request handler is ~4-5 (but it can stretch beyond that sometimes).</div>
<div>In that kind of application, is having yet another thread pool going to be useful?</div><div><br></div><div>I was wondering, is there a way to combine SimpleChannelHandler with <span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">ExecutionHandler in the standard Netty API, for convenience's sake? I suggest the name of DelegatedChannelHandler.</span></div>
<div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><br></span></div><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; ">Regards,</span></div>
<meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br clear="all">Marc-André LAVERDIÈRE<br>"Perseverance must finish its work so that you may be mature and complete, not lacking anything." -James 1:4<br>
<a href="http://mlaverd.theunixplace.com/blog">mlaverd.theunixplace.com/blog</a><br><br> /"\<br> \ / ASCII Ribbon Campaign<br> X against HTML e-mail<br> / \<br>
<br><br><div class="gmail_quote">2010/6/7 "Trustin Lee (이희승)" <span dir="ltr"><<a href="mailto:trustin@gmail.com">trustin@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Yes, only one event at a time will flow through individual channel<br>
handlers in the same pipeline in Netty. However, this is somewhat<br>
different from SEDA. It's not because of the queues but because of how<br>
pipeline is implemented.<br>
<br>
When an event is triggered, Netty calls the handler directly. It means<br>
Netty I/O thread will wait for your handler to return the control back.<br>
Until Netty takes the control back, Netty will not generate any event.<br>
Also, the same applies to event propagation in the pipeline.<br>
Forwarding an event to the next handler is simply calling the handler<br>
directly.<br>
<br>
To let user implement SEDA, Netty provides ExecutionHandler, which has a<br>
queue and a thread pool in org.jboss.netty.handler.execution. If you do<br>
not like it, you can always write your own handler that decouples the<br>
event execution from the Netty I/O threads.<br>
<br>
HTH,<br>
Trustin<br>
<br>
falconair wrote:<br>
> Does netty's ChannelHandler semantics include a guarantee that only one<br>
> message at a time will flow through individual channel handlers?<br>
><br>
> I didn't read any such thing in the docs, but I understand netty is based on<br>
> SEDA architecture, and I understand SEDA includes such guarantee.<br>
><br>
> In other words, which is more accurate representation of netty:<br>
><br>
> [h1]->[h2]->[h3]<br>
><br>
> or<br>
><br>
> {q1}==>[h1]->{q2}==>[h2]->{q3}==>[h3]<br>
><br>
> In the first scenario, multiple [h2] handler might be invoked for the SAME<br>
> pipeline, which means instance variables are prone to threading issues.<br>
><br>
> In the second scenario, interleaved queues make sure only one message is<br>
> processed by handler (for the same pipeline), therefore instance variables<br>
> are safe from dead-locks and race conditions.<br>
<font color="#888888"><br>
--<br>
what we call human nature in actuality is human habit<br>
<a href="http://gleamynode.net/" target="_blank">http://gleamynode.net/</a><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>
</font></blockquote></div><br></div>