Ray:
Are you digging into one of those Grizzly versions prior to Grizzly2.0?
Ming Qin
Cell Phone 858-353-2839
--- On Mon, 3/29/10, Ray Racine <ray.racine_at_gmail.com> wrote:
From: Ray Racine <ray.racine_at_gmail.com>
Subject: Selector Thread Processing Insight
To: users_at_grizzly.dev.java.net
Date: Monday, March 29, 2010, 4:11 PM
I'm trying to get an intuition on basic handling of an HTTP request and the various thread pools available to service requests. The below is a "guess" from an afternoon code crawl. Corrections _are_ appreciated.
1. For a given port, say 8080, there is only ONE SelectorThread. It is literally a single thread. Only this thread is capable of processing an OP_ACCEPT on the port (listener socket). (????)
3. At some point when reading via the these polled reader threads, the request channel is handed off to a ProtocolFilter as a Task on its own WorkerThread, by default this is (wait for it) the DefaultProtocoalFilter! which is specifically a HTTP protocol filter/handler.
4. In turn the ProcessorTask MAY be configured to support async writing. If this is so, then a different selector (if available) will be used to perform the final output of the request.
This gives up to 3 logic thread pools, one for a pool of reader threads, one for a pool of worker threads, and one for a pool of writer threads.
Close so far???
Do all of these share the ExecutorService threadPool in the SelectorThread. In other words if the SelectorThread.threadPool max threads is say 100. Then at most one can have 100 active readers, workers and writers?
Thanks,
Ray
--
The object of life is not to be on the side of the majority, but to escape finding oneself in the ranks of the insane. - Marcus Aurelius