Salut,
charlie hunt wrote:
> I should look back at the work we started about a year ago with what we
> thought at the time was gonna be Grizzly V2 (currently abandoned) and
> how we were initially going to support multiple selectors. Maybe this
> is further evidence that we should get that work we started a year
> pushed out to Project Grizzly so it's more accessible to us ?
It is not multiple Selector like the work we did for v2. We already
support multiple Selector (thanks to Alexey) :-)
>
>
> IIRC, I think we had something like a TransportManager abstraction that
> took information from a TransportConfiguration which setup the multiple
> selectors which each selector event loop running in its own distinct
> thread. Again, maybe further evidence we should move that (abandoned)
> work to Project Grizzly some where.
Let discuss the difference between 'multiple Selector' versus multiple
SelectorHandler as I think they are not exactly the same. A
SelectorHandler can always handles more than one Selector. The problem
is how the Controller handles all the SelectorHandler (with a single or
more Selector). I think the current solution we support for multiple
Selector is fine (can always be improved)....but the multiple
SelectorHandler support is not performant, hence we need to do something :-)
A+
-- Jeanfrancois
>
> charlie ..
>
> Jeanfrancois Arcand wrote:
>> Hi,
>>
>> between version 1.5.1 and 1.5.2, I've added support for more that one
>> SelectorHandler per Controller based on requests sent to that mailing
>> list (Alexey, remove my commits privileges!!!!). At the time I was
>> under the impression it will be great to have a single Controller that
>> can manipulate several SelectorHandler. Well, I still think this is a
>> good idea except performance/implementation wise (like I've learned
>> working on the Sailfin project where Grizzly was almost 20 times
>> slower than the Ericsson implementation (maybe more!)), the current
>> implementation doesn't perform well.
>>
>> The problem is when the controller invoke its SelectorHandler
>> preSelect, select and postSelect, the SelectorHandler implementation
>> can block on the Selector.select(timeout), delaying the invocation of
>> others SelectorHandler. To see it in action, just creates 3
>> SelectorHandler (tcp|udp|tls). When the Controller loops:
>>
>>
>>> 277
>>> 278 selectorHandler.preSelect(serverCtx);
>>> 279
>>> 280 readyKeys = selectorHandler.select(serverCtx);
>>> 281 selectorState = readyKeys.size();
>>
>>
>> if there is an ops ready for the last added SelectorHandler (any
>> SelectorHandler), the invocation will be delayed by almost 3
>> seconds....you can imagine how bad the performance will be :-). Thus
>> we need to think about a way to simultaneously/concurrently invoke all
>> the SelectorHandler (most probably using a Thread pool) to avoid such
>> performance hit.
>>
>> For Sailfin, I've created 3 Controller and now the performance is
>> really good ;-). Any volunteers to work on that knowing that my last
>> couple of commits are so bad :-)?
>>
>> The current performance is so bad when more than one SelectorHandler
>> are added right now that it deserve a 1.6.1 release just to fix this :-)
>>
>> Charlie, can you add an item to the next phone meeting :-) :-)
>>
>> Thanks,
>>
>> -- Jeanfrancois
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>>
>
>