Fyi ... some systems with a very large number of virtual processors,
especially those with a large number of connections which "connect and
release" frequently, will likely perform better with multiple selectors.
hths,
charlie ...
Jeanfrancois Arcand wrote:
> Salut,
>
> ming qin wrote:
>> Hi Everyone:
>>
>> After examining a few classes in Grizzly 1.5.0 and Grizzly 1.9.X
>> such as Controller( initReadThread(), copyto() ), Cloner ( clone())
>> , TCPSelectHandler, WorkerThreadImpl, RoundRobinSelectorHandler and
>> Controller’s shallow copy on TCPSelectorHandler’s selector property
>> to ReadController ), my impression is that Grizzly’s selector design
>> was aligned with Ron’s recommendation on having single selector.
>
> Not sure who came with the idea first :-) Usually you should have one
> acceptor(Selector) per core, not more. This is what we came with a
> couple of years ago.
>
>>
>>
>>
>> Is my conclusion right? How does grizzly 2.o handle this issue (
>> multiple selectors vs. single selector)
>
> Should be supported as well.
>
> A+
>
> -- Jeanfrancois
>
>
>
>
>
>
>>
>>
>> See below Ron’s recommendation on this subject
>>
>>
>>
>> Ron Hitchens ( his 2002 book <<Java NIO>> chapter 4 section 5 –
>> Selection Scaling) argued that “A better approach is to use one
>> selector for all selectable channels and delegate the servicing of
>> ready channels to other threads. You have a single point to monitor
>> channel readiness and a decoupled pool of worker threads to handle
>> the incoming data. The thread pool size can be tuned (or tune itself,
>> dynamically) according to deployment conditions. Management of
>> selectable channels remains simple, and simple is good.”
>>
>>
>>
>>
>> Ming Qin
>> Cell Phone 858-353-2839
>>
>> -
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>