The link http://weblogs.java.net/blog/jfarcand/archive/2006/06/tricks_and_tips.htmlis broken.
Does the discussion points to http://weblogs.java.net/blog/2006/06/06/tricks-and-tips-nio-part-ii-why-selectionkeyattach-evil? thanks ashish On Wed, Oct 21, 2009 at 1:01 PM, <[email protected]> wrote: > MINA 3.0 > design<http://cwiki.apache.org/confluence/display/MINA/MINA+3.0+design> Page > *edited* by Julien > Vermillard<http://cwiki.apache.org/confluence/display/%7Ejvermillard> > > Due to the way Confluence modifies the pages when it opens it in the > RichText editor, the presentation is totally screwed up when saving in this > mode. > > Until we find a way to keep the cool HTML presentation we currently have, > please *don't* save this page if you have edited it on Rich Text format. > Try to edit it in Wiki Markup instead. > > Thanks ! > Introduction > > This page is intended to be a place open for discussion about MINA 3.0 > features. Comments and ideas are very welcome ! > Mina 3.0 design and expected features > > Some thoughts about what I see important to have in MINA 3.0... > 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 *vrm > :*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 manipulate, 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 *vrm :* 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. *ede :* Tricky : will this affect only new > sessions or started sessions too ? > *ele :* All the sessions. I don't see a clear and easy to implement > mechanism to protect the current sessions from such a change. Npw, as the > chain is just a structure used to keep a list of filter to go through, it > should be easy to guarantee that a session requesting the next filter is > not > affected by the change. > > > - 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) *vrm :* 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 > *vrm :* What is that for ? Look like you got a new idea :) > *ele :* Nothing new there : it's just to allow SEDA implementation. > > > - the Head and Tail filters are useless : they should be removed *vrm : > * Yes > *ede :* These are just implementation details of the actual chain > > > - a chain may not be a list of filters. It can be a graph *vrm :* If we > can keep the API simple enough, why not. > *ede :* This imho will greatly increase the complexity of the chain ( > cycle detection mechanism ?) > *ele :*Yes, this is probably not the most simple thing to implement ... > > 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. > *vrm :* You want to say multi layer codec ? > *ele :* That's a part of it. > > > - the executor filter could be present in more than one place in the > chain (SEDA) *vrm :* Mandatory if someone really want SEDA. > *ele :* Plus we need to have queues in the middle. Maybe we should call > it SedaFilter instead... > > > - statistic must be established with a filter *vrm :* Again mandatory. > You won't do stats the same way on HTTP or FTP and stats can be very costy. > *ede :* Moreover they actually are not accurate and only darken the > code ... > > > - we should define two interfaces for filters : IngoingFilter and > OutgoingFilter. They will expose the methods to process ingoing and > outgoing > messages *vrm :* The question is where to put sessionOpen/Closed/Idle > in a two chains model. > *ele :* As the session is managed at the upper level, such messages > must be propagated from the processor to the handler, not the way around. > *ede :* So sessionOpen/Closed/Idle should be added to IncomingFilter. > What about ExceptionCaught event ? > *ele :* ExceptionCaught event are not supposed to be incoming event, > AFAIK... > > > - The SSL filter should not be a filter at all: it's a part of the > underlying protocol, and the handshake should be done previously to any > kind > of exchange. Another option would be to move this filter in the first > position in the chain. > > Session > > - we should have two kind of sessions : stateful and stateless. > Sometime, we don't need to store any kind of information in a session *vrm > :* If we create the HashMap on first additon, where is the gain ? > *ele :* If a session is stateful, not creating a structure to store > data which won't be added will eat less memory. We can create this > container > only when necessary, obviously when the session is created, but then if we > have two kind of session classes, we will immediately know when to create > this container. > *vrm :* How to manage idle time with a stateless IoSession ? > > > - we should add a sessionManager instead of all the existing queues > used to manage the dead sessions, the idle sessions, etc. *vrm :* 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. *vrm : > * +1 > > > - If a session is stateful, then we should attach the data to the > channel instead of creating a map for that *vrm :* Can you say more > about that, where is the gain ? > *ele :* Simplicity : no need to define a container which already > exists, as you can attach Objects to the SelectionKey. Jean-François Arcand > has blogged about how dangerous it is : > http://weblogs.java.net/blog/jfarcand/archive/2006/06/tricks_and_tips.html, > but this is dangerous *if* one code its own server without dealing with > session expiration. As we are defining a framework, this is not a problem > for us. > *vrm :* So you want to trash all the session hashmap and just give > access to the attachement of an Object at the NIO level ? > > > - 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 > *vrm :* 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, but it can change. > *ele :* ADS deal with LDAP, DNS, Kerberos, Ntp, Dhcp. Atm, we create > one NioAcceptor per protocol, a bit overkilling (not to mention that we > have > as many NioProcessors... > > *ele :* Moreover, I think that the name we are using is incorrect. An > acceptor or a connector are not services, but transports. They just take > care of incoming connections, sessions creation and data transfert. The real > service is the implemented protocol, which is handler by the session's > chain, all the filters and the handler. If we also combine the configuration > with the service, we are golden. MINA 3.0 must reflect this. > > - It should be possible to close a session on a specific message > reception, without having to add a listener for that *ede :* use case ? > > *ele :*Atm, if one want to close a session in a filter (black list) or > in the handler, it's a bit tricky, as a listener must be added in order to > close the session. This mechanism is cumbersome > > codec > > - we don't have stateful or stateless codecs. We should distinguish the > two kinds of codec someone can use. *vrm :* +1 > - we should define a collection of existing codecs *vrm :* For that we > need a standard way of doing a codec on the Pojo side. I'm sure LDAP pojo > for ADs are very different (and got different dependencies) of the one of > Asyncweb or Vysper. > *ele :* They are very different. The codec should define not only the > encoder and the decoder, but the associated POJOs. > - as we can handle more than one protocol, we must add a demuxingCodec > which point to the next filter, conditionally *vrm :* Here the graph ? > :) > *ele :* Yes > > Buffer > > - We should not wrap ByteBuffer into our own IoBuffer class. We should > have a list of ByteBuffers instead, containing all the ByteBuffers. *vrm > :* And some extended Stream interface for manipulation. > - The chain API should be modified to expose Streams of generic types > (Stream<K>) instead of IoBuffer, allowing us to add more than one codec > filter in the chain (each Filter being aware of the kind of Object it can > manipulate) > > General > > - offer a NIO 2.0 library *vrm :* Well it's going to be soon mandatory > :) > - Use real Future implementation > - Support Multicast > - Create a benchmark suite > > This is just a starting point ... > *vrm :* 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. > Change Notification > Preferences<http://cwiki.apache.org/confluence/users/viewnotifications.action> > View Online<http://cwiki.apache.org/confluence/display/MINA/MINA+3.0+design>| > View > Change<http://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=120101&revisedVersion=14&originalVersion=13>| > Add > Comment<http://cwiki.apache.org/confluence/display/MINA/MINA+3.0+design?showComments=true&showCommentArea=true#addcomment> >
