One message at a time in each handler?

["이희승 (Trustin Lee)"]

Yes, you should handle the events in a different thread pool than the 
Netty I/O threads, typically using ExecutionHandler.

There is no way to combine SimpleChannelHandler and ExecutionHandler. 
It's actually very simple to add two handlers into the pipeline, so I'm 
not sure introducing such a class is a good idea.

HTH,
Trustin

On 06/07/2010 01:49 PM, Marc-André Laverdière wrote:
> I was wondering which option would be the best for my app, SEDA or not?
>
> 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).
> In that kind of application, is having yet another thread pool going to
> be useful?
>
> I was wondering, is there a way to combine SimpleChannelHandler with
> ExecutionHandler in the standard Netty API, for convenience's sake? I
> suggest the name of DelegatedChannelHandler.
>
> Regards,
>
> Marc-André LAVERDIÈRE
> "Perseverance must finish its work so that you may be mature and
> complete, not lacking anything." -James 1:4
> mlaverd.theunixplace.com/blog <http://mlaverd.theunixplace.com/blog>
>
> /"\
> \ /    ASCII Ribbon Campaign
>   X      against HTML e-mail
> / \
>
>
> 2010/6/7 "Trustin Lee (이희승)" <trustin at gmail.com
> <mailto:trustin at gmail.com>>
>
>     Yes, only one event at a time will flow through individual channel
>     handlers in the same pipeline in Netty.  However, this is somewhat
>     different from SEDA.  It's not because of the queues but because of how
>     pipeline is implemented.
>
>     When an event is triggered, Netty calls the handler directly.  It means
>     Netty I/O thread will wait for your handler to return the control back.
>       Until Netty takes the control back, Netty will not generate any event.
>       Also, the same applies to event propagation in the pipeline.
>     Forwarding an event to the next handler is simply calling the handler
>     directly.
>
>     To let user implement SEDA, Netty provides ExecutionHandler, which has a
>     queue and a thread pool in org.jboss.netty.handler.execution.  If you do
>     not like it, you can always write your own handler that decouples the
>     event execution from the Netty I/O threads.
>
>     HTH,
>     Trustin
>
>     falconair wrote:
>      > Does netty's ChannelHandler semantics include a guarantee that
>     only one
>      > message at a time will flow through individual channel handlers?
>      >
>      > I didn't read any such thing in the docs, but I understand netty
>     is based on
>      > SEDA architecture, and I understand SEDA includes such guarantee.
>      >
>      > In other words, which is more accurate representation of netty:
>      >
>      > [h1]->[h2]->[h3]
>      >
>      > or
>      >
>      > {q1}==>[h1]->{q2}==>[h2]->{q3}==>[h3]
>      >
>      > In the first scenario, multiple [h2] handler might be invoked for
>     the SAME
>      > pipeline, which means instance variables are prone to threading
>     issues.
>      >
>      > In the second scenario, interleaved queues make sure only one
>     message is
>      > processed by handler (for the same pipeline), therefore instance
>     variables
>      > are safe from dead-locks and race conditions.
>
>     --
>     what we call human nature in actuality is human habit
>     http://gleamynode.net/
>
>     _______________________________________________
>     netty-users mailing list
>     netty-users at lists.jboss.org <mailto: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

-- 
what we call human nature in actuality is human habit
http://gleamynode.net/