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
