(sorry, I don't know how this message got sent to you directly !)
Salut Jeanfrancois,
> have you made any progress? Let me try to answer
> questions...sorry for the delay
Np, well actually I'm pretty busy with another project so I still haven't
had the time to actively work on Grizzly... I'm just trying to understand
the overall picture, so that when I'm ready I'll know where to start from.
> The thread pool used in Grizzly, called Pipeline, is an home
> made thread pool. At the time we wrote Grizzly, the
> java.util.concurrent.* one weren't preforming as good as that
> one. Now we will soon move to an Executor based one.
I guess that if I start writing a project with Grizzly now, and you later
move to the new thread pool, no changes will be required from my side. Am I
guessing right (at least I hope so!)
> or is it used for Handlers processing?
>
> By handlers, you means ProtocolFilter?
I'm studying both Grizzly and Mina, so maybe I got the terms mixed up.
I mean the component that contains my application logic.
So the expected scenario is like this (please correct me if I got it wrong):
The Selector thread (N+1 threads per N Cpu) handles the ACCEPT operation for
each new connection, stores the connection reference (selector key) then
passes it to a new thread for the protocol filtering (which is the parsing
action in the case of a text based protocol like an xml-based one, right?).
At this point, say the client sent a command "doSomething", which results in
several operations to be performed by the server (eg. Querying a db,
creating some object instances and so on). Are these operations done by that
same thread or is it a new thread different from the one that filtered the
protocol?
Thanks again,
Matteo