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 ?
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.
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
>
--
Charlie Hunt
Java Performance Engineer
630.285.7708 x47708 (Internal)
<http://java.sun.com/docs/performance/>