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...

• 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 ...