One message at a time in each handler?

[Marc-André Laverdière]

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

/"\
\ /    ASCII Ribbon Campaign
 X      against HTML e-mail
/ \


2010/6/7 "Trustin Lee (이희승)" <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
> https://lists.jboss.org/mailman/listinfo/netty-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/netty-users/attachments/20100607/356e6631/attachment.html