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