Hi Matteo,
>
> The Selector thread (N+1 threads per N Cpu) handles the ACCEPT operation
> for
I think this is configurable.
if you start one controller out of the box
it is only one thread.
> 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?
These operations are done by "the same thread that filtered the protocol"
Of course you often then end up blocking on jdbc calls.
So you loose some of the "Threading" advantages you gained by NIO.
I find it a very interresting question to try to avoid
blocking of for example jdbc calls. Has anybody done
any code?
Many Greetings
John
--
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger