You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Ashish <pa...@gmail.com> on 2009/10/21 10:16:50 UTC
Re: [CONF] Apache MINA > MINA 3.0 design
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, <co...@apache.org> 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>
>
Re: [CONF] Apache MINA > MINA 3.0 design
Posted by Ashish <pa...@gmail.com>.
My mistake, the link is working fine. Some local browser problem :-(
thanks
ashish
On Wed, Oct 21, 2009 at 1:46 PM, Ashish <pa...@gmail.com> wrote:
> 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
>
>
> thanks
ashish
Blog: http://www.ashishpaliwal.com/blog
My Photo Galleries: http://www.pbase.com/ashishpaliwal