Hi, reply inline Le Wed, 10 Jun 2009 21:37:10 +0200, Emmanuel Lecharny <elecha...@apache.org> a écrit :
> Hi guys, > > as I'm commuting every day for a long distance, I have had time to > think about what I would see in MINA 3.0. Here is the result of my > random thoughts.... And not see anymore ;) > > > Mina 3.0 design and expected features > ------------------------------------- > > - selectors usage > We should be able to define the number of selectors to use, and to > define what they will be used for. For instance, atm, we have a > selector in the Acceptor, plus a selector per Processor. This is not > necessarily the best solution. > > * do some perf tests to see if it's better to use one or many > selectors. > * decouple the selector usage from the the selector definition. It > should be possible to define one single selector and use it in many > places > * the Acceptor and Processor should not necessarily be associated > with a thread. it's up to the user to define the thread model to use Actually look like we need different strategy for different usage. On the right threading/selector strategy look like there is no real consensus and we will need to experiment for finding the default solution. > - Chain > The current chain implemention is cumbersome. We would like to have > something easier to manipluate, and also easier to debug. > > * the chain should be optionally dynamic : a session can add a new > filter in the chain whenever needed > * we should not always copy the chain in each session, if the chain > is immutable Yes, cause most of time we configure the chain on the acceptor and never change it again. Look like we agreed on copy-on-write for that. > * however, it should be possible to change the global chain without > breaking the processing. > * we should have one chain for incoming messages, and another one for > outgoing messages > * it should be possible to have a multi-stage codec (ie, add more > than one codec filter in the chain) Mandatory, it's very often I use a TextLineCodec and a String-to-Pojo filter, and I'm sure I'm not alone. > * we should allow a queuing mechanism to be put in between each > filters What is that for ? Look like you got a new idea :) > * the Head and Tail filters are useless : they should be removed Yes > * a chain may not be a list of filters. It can be a graph If we can keep the API simple enough, why not. > - Filters > > * a filter should accept a stream<Object>, the Object can change from > one filter to another. it's up to the user to correctly handle the > Object. You want to say multi layer codec ? > * the executor filter could be present in moe than one place in the > chain (SEDA) Mandatory if someone really want SEDA. > * statistic must be established with a filter Again mandatory. You won't do stats the same way on HTTP or FTP and stats can be very costy. > * we should define two interfaces for filters : IngoingFilter and > OutgoingFilter. They will expose the methods to process ingoing and > outgoing messages The question is where to put sessionOpen/Closed/Idle in a two chains model. > > - Session > * we should have two kind of sessions : statefull and stateless. > Sometime, we don't need to store any kind of information in a session If we create the HashMap on first additon, where is the gain ? > * we should add a sessionManager instead of all the existing queues > used to manage the dead sessions, the idle sessions, etc. We need to rethink the whole separation between IoProcessor and IoService and where we manage closing/accepting queues. > * session should not necessarily be associated with a processor. +1 > * If a session is statefull, then we should attach the data to the > channel instead of creating a map for that Can you say more about that, where is the gain ? > * A session must be attached to an acceptor, allowing more than one > chain if the acceptor is to deal with more than one single > SocketServer We need to find away for running more than 1 kind of port/protocol with the same set of Thread/Executors. I suppose it would be interesting for ADS. On my side I run servers with 3 or 4 SocketAcceptors for different protocols, somthing like 10 SocketConnectors for different protocols. Perfs aren't an issue for me actually, be it can change. > > - codec > * we don't have stateful or stateless codecs. We should distinguish > the two kinds of codec someone can use. +1 > * we should efine a collection of existing codecs For that we need a standard way of doing a codec on the Pojo side. I'm sure LDAP pjo oof ADs are very different (and got different dependencies) of the one of Asyncweb or Vysper. > * as we can handle more than one protocol, we must add a > demuxingCodec which point to the next filter, conditionally Here the graph ? :) > > - Buffer > * We should not wrap ByteBuffer into our own IoBuffer class. We > should have a list of ByteBuffers instead, containing all the > ByteBuffers. And some extended Stream interface for manipulation. > > - General > * offer a NIO 2.0 library > Well it's going to be soon mandatory :) > > This is just a starting point ... Feel free to comment, add or remove > some items ! > We need at first a great test platform for testing the different protocols and implementation ideas (Thread/Selector/Channel strategies). So we make choice based on facts for the engine. Julien
signature.asc
Description: PGP signature
