One message at a time in each handler?
Chew Kok Hoor
kokhoor at gmail.com
Wed Jun 16 12:40:27 EDT 2010
Hi,
1. Sorry for my ignorance, just curious, does this means when using
the ExecutionHandler, it is possible for a Client connection to send
multiple requests to the server at one time, and then wait for the
responses for all the requests to come back?
2. If this is the case, what if user sends a Login command followed
by a say Chat command. If the messages are processed concurrently,
surely the Chat command should return an 'Unauthorized access', right?
Or is the timing of the Send has to be controlled by the Client so
client only sends multiple requests when it is possible for it to (say
after its login info has been authenticated.
3. Based on documentation on ExecutionHandler, it is mentioned 'You
can implement an alternative thread model such as SEDA by adding more
than one ExecutionHandler to the pipeline.'.
I do not get how adding more than one ExecutionHandler will
help performance. When you have one ExecutionHandler, doesn't it runs
on its own thread already? How would subsequent ExecutionHandler works
in this scenario?
Regards,
Kok Hoor
2010/6/16 Marc-André Laverdière <marcandre.laverdiere at gmail.com>
>
> You're right, adding the execution handler is pretty simple. I put it
> in my pipeline, and it looks like its vastly improving the performance
> (~3x).
> If that's the case, why not make it a default?
> 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/12 "이희승 (Trustin Lee)" <trustin at gmail.com>:
> > 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/
> > _______________________________________________
> > 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
More information about the netty-users
mailing list