A multi-reactor nio scheduler

11 views
Skip to first unread message

dennis

unread,
Aug 22, 2010, 11:40:40 PM8/22/10
to kilimthreads
Hi,everybody

Kilim 0.7 has introduced a new scheduler——NioSelectorScheduler for
schduling io events,it is a great a progress.
But it only use one SelectorThread to schdule tasks,insead mina or
netty such these nio frameworks have used more nio workers(reactor) to
handle io events for performance.

So i have made a branch to implement a new NioSelectorScheduler,which
use some nio workers to schedule tasks more than one.In my test,it has
much better performance than original NioSelectorScheduler.

If someone interested, please clone it from github http://github.com/killme2008/kilim

Sriram Srinivasan

unread,
Aug 23, 2010, 1:21:15 AM8/23/10
to kilimt...@googlegroups.com
Hi Dennis,

Thanks for your effort. I have not looked at your changes yet, but
would like to examine your assumptions here.

Nothing prevents anyone from creating multiple NioSelectorScheduler
instances (hence multiple selector threads) each of which manages its
own set of tasks, just like any scheduler, and its own set of sockets.
The one part I have not implemented is transparent migration of a task
from one NioSelector to another, because that would entail
deregistration from one first. But the intention has always been to
support any number of NioSelectorSchedulers.

I'd love to hear from you where you think this is limited.

Thanks.

--sriram.

dennis

unread,
Aug 23, 2010, 3:36:49 AM8/23/10
to kilimthreads
hi sriram

Yes,you are right,i can create multiple NioSelectorScheduler instances
each of which manages its own set of tasks.

But the ListenTask only has one NioSelectorScheduler instance,and if a
new connection accpted and create a new SessionTask,it could not be
scheduled by other NioSelectorScheduler instances except the listen
task owns.And then,all io events have to be handled only by one
java.nio.chanels.Selector instance,and with many connections the
selector could be the performance bottleneck.

Best Regards

--dennis
Reply all
Reply to author
Forward
0 new messages