[ http://issues.apache.org/jira/browse/DIRMINA-119?page=comments#action_12359046 ]
dave irving commented on DIRMINA-119: ------------------------------------- > There could be a default singleton SocketIoProcessorPool: > SocketIoProcessorPoolImpl.getDefaultInstance() > which is used by all SocketIoAcceptor/Connector instances by default. The only problem is that there is no "close" (or similar) in IoConnector - and users can create connectors when ever they like. Thus theres no clean way to de-register the exception monitor from the exception monitor proxy for the connector. Hmmm........ > One question: why do we need associateProcessor(IoSession s)? Couldn't it > just have a getIoProcessor() > method? SocketIoAcceptor/SocketIoConnector would get a processor using this > method and give it to the > SocketSessionImpl when constructed. I dont mind either way. The reason I did it this way is to avoid package dependency leak. The main interfaces (SocketSessionManager / SocketIoProcessorPool) are in socket.nio. The "how its done" (including the SocketIoProcessor class and SocketSessionImpl) is in socket.nio.support. So this way all the implementation details of the processing strategy for a session is within nio.support. Maybe a better name would be SocketIoProcessingStrategy (and maybe startForSession instead of associateProcessor). I dont mind either way though. > Multiple selector loops > ----------------------- > > Key: DIRMINA-119 > URL: http://issues.apache.org/jira/browse/DIRMINA-119 > Project: Directory MINA > Type: Improvement > Versions: 0.8 > Environment: All. Benefit is dependant on environment > Reporter: dave irving > Assignee: Trustin Lee > Priority: Minor > Fix For: 0.9 > Attachments: prototype.zip > > Mina's SocketIoProcessor currently owns a Selector and employs a single > Worker to run the NIO "selector loop". > I have been running tests where Im trying to maximise throughput and have > found - that in certain multi-cpu environments - this worker thread can > encounter a large amount of starvation even though CPU usage is fairly low. > By testing 2 selector-loops instead of 1, I managed to improve my overall > test throughput by just under 30%. > The general idea is to do this: > - Each SocketIoProcessor.Worker encapsulates its own work queues associated > Selector > - It should be possible to configure the number of Workers (and thus > selectors) employed by SocketIoProcessor > - When a SocketSession is added to the SocketIoProcessor, a Worker is > selected (round-robin) which will be associated with the SocketSession for > its lifetime. This association is managed by SocketSession (get/setWorker) > - When someone asks SocketIoProcessor to do some work to a session, instead > of doing it directly, the processor now asks the session for its Worker, and > delegates to the worker (i.e, the same worker is always used for an > individual session) > I've done some prototyping, and have also checked that the concept works with > the latest build. > The prototype is very hacky - mainly because there are some refactoring > issues i'd like feed-back on before I submit a "proper" patch for review. > Namely: > - How do you want me to tell the SocketIoProcessor how many workers to use? > One option is a system property - but thats pretty hacky. I dont think we > need to support changing the number of workers after operation has begun > (It'll probably be a function of the number of available CPUs) - and this > makes the code simpler. However, as SocketIoProcessor is a (non lazy created) > singleton, we need a way to get the param in. We could refactor, or maybe > introduce a ProcessorOptions class or something. The SocketIoProcessor could > interrigate this when initializing. Any direction on your desired approach > would be appreciated > Cheers, > Dave -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
