users@grizzly.java.net

Re: Selector Thread Processing Insight

From: Ray Racine <ray.racine_at_gmail.com>
Date: Mon, 29 Mar 2010 22:08:11 -0400

I'm digging into trunk. I think that is 1.9.x and not 2.0.

On Mon, Mar 29, 2010 at 8:00 PM, Ming Qin <mingqin1_at_yahoo.com> wrote:

> 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). (????)
>
> 2. However a SelectorThread MAY be configured to use a pool of reader
> threads by setting the readerThreadCount to some positive number. This
> spreads the load for OP_READ reads across several threads. This is done
> inside the SelectorThread's Controller. In this case the Controller's
> SelectorHandler is an instance of RoundRobinSelectorHandler which handles
> the reads with a thread pool.
>
> 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.
>
> Endpoint [ACCEPT] (1 Selector/Thread) ->
> Readers [READ] (N ReadSelectors/Threads) ->
> ProtocolFilter [READ??, PROCESS_REQUEST_IN_ADAPTER](M WorkerTasks/Threads)
> ->
> OutputWriter [WRITE] (L WriteSelectors/Threads)
>
>
> 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
>
>


-- 
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