[prev in list] [next in list] [prev in thread] [next in thread]
List: mina-commits
Subject: [CONF] Apache MINA > MINA 3.0 design
From: confluence () apache ! org
Date: 2010-08-19 13:07:00
Message-ID: 5475523.10750.1282223220499.JavaMail.confluence () thor
[Download RAW message or body]
<html>
<head>
<base href="https://cwiki.apache.org/confluence">
<link rel="stylesheet" \
href="/confluence/s/1810/9/1/_/styles/combined.css?spaceKey=MINA&forWysiwyg=true" \
type="text/css"> </head>
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
<h2><a href="https://cwiki.apache.org/confluence/display/MINA/MINA+3.0+design">MINA \
3.0 design</a></h2> <h4>Page <b>edited</b> by <a \
href="https://cwiki.apache.org/confluence/display/~paliwalashish@gmail.com">Ashish \
Paliwal</a> </h4>
<br/>
<h4>Changes (1)</h4>
<div id="page-diffs">
<table class="diff" cellpadding="0" cellspacing="0">
<tr><td class="diff-snipped" >...<br></td></tr>
<tr><td class="diff-unchanged" >h2. Debugging tool <br>{html}<div \
class="vrm"><strong>ashish:</strong> We need debugging tool \
for easy debugging of MINA Apps. We can explore VisualVM plugin for achieving the \
same or a standalone UI.</div> <br></td></tr> <tr><td class="diff-added-lines" \
style="background-color: #dfd;"> \
<br>!http://www.gliffy.com/pubdoc/2060745/L.png|border=1! <br> <br>Captured some \
initial thoughts on the tool. JMX based interface would be the most preferred choice \
<br> <br></td></tr> <tr><td class="diff-unchanged" >{html} <br> <br></td></tr>
<tr><td class="diff-snipped" >...<br></td></tr>
</table>
</div> <h4>Full Content</h4>
<div class="notificationGreySide">
<style TYPE="text/css">
.ele
{
padding-left:10px;
border-left: 2px solid;
border-color: green;
background-color: #DDFFBB;
}
.ede
{
padding-left:10px;
border-left: 2px solid;
border-color: #7500EA;
background-color: #BCBBFF;
}
.vrm
{
padding-left:10px;
border-left: 2px solid;
border-color: red;
background-color: #FFCCBB;
}
</style>
<div class='panelMacro'><table class='warningMacro'><colgroup><col \
width='24'><col></colgroup><tr><td valign='top'><img \
src="/confluence/images/icons/emoticons/forbidden.gif" width="16" height="16" \
align="absmiddle" alt="" border="0"></td><td>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.
<p>Until we find a way to keep the cool HTML presentation we currently have, please \
<b>don't</b> save this page if you have edited it on Rich Text format. Try to edit it \
in Wiki Markup instead.</p>
<p>Thanks !</p></td></tr></table></div>
<h1><a name="MINA3.0design-Introduction"></a>Introduction</h1>
<p>This page is intended to be a place open for discussion about MINA 3.0 features. \
Comments and ideas are very welcome !</p>
<h1><a name="MINA3.0design-Mina3.0designandexpectedfeatures"></a>Mina 3.0 design and \
expected features</h1>
<p>Some thoughts about what I see important to have in MINA 3.0...</p>
<h2><a name="MINA3.0design-selectorsusage"></a>selectors usage </h2>
<p>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.</p>
<ul>
<li>do some perf tests to see if it's better to use one or many selectors.</li>
<li>decouple the selector usage from the the selector definition. It should be \
possible to define one single selector and use it in many places</li> <li>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 <div class="vrm"><strong>vrm :</strong>
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.
</div></li>
</ul>
<h2><a name="MINA3.0design-Chain"></a>Chain</h2>
<p>The current chain implemention is cumbersome. We would like to have something \
easier to manipulate, and also easier to debug.</p>
<ul>
<li>the chain should be optionally dynamic : a session can add a new filter in the \
chain whenever needed</li> </ul>
<ul>
<li>we should not always copy the chain in each session, if the chain is immutable
<div class="vrm"><strong>vrm :</strong>
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. </div></li>
</ul>
<ul>
<li>however, it should be possible to change the global chain without breaking the \
processing. <div class="ede"><strong>ede :</strong> Tricky : will this affect only \
new sessions or started sessions too ? </div> <div class="ele"><strong>ele :</strong> \
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. </div></li> </ul>
<ul>
<li>we should have one chain for incoming messages, and another one for outgoing \
messages</li> </ul>
<ul>
<li>it should be possible to have a multi-stage codec (ie, add more than one codec \
filter in the chain) <div class="vrm"><strong>vrm :</strong>
Mandatory, it's very often I use a TextLineCodec and a String-to-Pojo filter, and I'm \
sure I'm not alone. </div></li>
</ul>
<ul>
<li>we should allow a queuing mechanism to be put in between each filters
<div class="vrm"><strong>vrm :</strong>
What is that for ? Look like you got a new idea :)
</div>
<div class="ele"><strong>ele :</strong>
Nothing new there : it's just to allow SEDA implementation.
</div></li>
</ul>
<ul>
<li>the Head and Tail filters are useless : they should be removed
<div class="vrm"><strong>vrm :</strong>
Yes
</div>
<div class="ede"><strong>ede :</strong> These are just implementation details of the \
actual chain</div></li> </ul>
<ul>
<li>a chain may not be a list of filters. It can be a graph
<div class="vrm"><strong>vrm :</strong>
If we can keep the API simple enough, why not.
</div>
<div class="ede"><strong>ede :</strong> This imho will greatly increase the \
complexity of the chain ( cycle detection mechanism ?) </div> <div \
class="ele"><strong>ele :</strong>Yes, this is probably not the most simple thing to \
implement ...</div></li> </ul>
<h2><a name="MINA3.0design-Filters"></a>Filters</h2>
<ul>
<li>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. <div \
class="vrm"><strong>vrm :</strong> You want to say multi layer codec ?
</div>
<div class="ele"><strong>ele :</strong>
That's a part of it.
</div></li>
</ul>
<ul>
<li>the executor filter could be present in more than one place in the chain (SEDA)
<div class="vrm"><strong>vrm :</strong>
Mandatory if someone really want SEDA.
</div>
<div class="ele"><strong>ele :</strong>
Plus we need to have queues in the middle. Maybe we should call it SedaFilter \
instead... </div></li>
</ul>
<ul>
<li>statistic must be established with a filter
<div class="vrm"><strong>vrm :</strong>
Again mandatory. You won't do stats the same way on HTTP or FTP and stats can be very \
costy. </div>
<div class="ede"><strong>ede :</strong> Moreover they actually are not accurate and \
only darken the code ... </div></li> </ul>
<ul>
<li>we should define two interfaces for filters : IngoingFilter and OutgoingFilter. \
They will expose the methods to process ingoing and outgoing messages <div \
class="vrm"><strong>vrm :</strong> The question is where to put \
sessionOpen/Closed/Idle in a two chains model. </div>
<div class="ele"><strong>ele :</strong>
As the session is managed at the upper level, such messages must be propagated from \
the processor to the handler, not the way around. </div>
<div class="ede"><strong>ede :</strong> So sessionOpen/Closed/Idle should be added to \
IncomingFilter. What about ExceptionCaught event ?</div> <div class="ele"><strong>ele \
:</strong> ExceptionCaught event are not supposed to be incoming event, \
AFAIK...</div></li> </ul>
<ul>
<li>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.</li> \
</ul>
<h2><a name="MINA3.0design-Session"></a>Session </h2>
<ul>
<li>we should have two kind of sessions : stateful and stateless. Sometime, we don't \
need to store any kind of information in a session <div class="vrm"><strong>vrm \
:</strong> If we create the HashMap on first additon, where is the gain ?
</div>
<div class="ele"><strong>ele :</strong>
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. </div>
<div class="vrm"><strong>vrm :</strong>
How to manage idle time with a stateless IoSession ?
</div></li>
</ul>
<ul>
<li>we should add a sessionManager instead of all the existing queues used to manage \
the dead sessions, the idle sessions, etc. <div class="vrm"><strong>vrm :</strong>
We need to rethink the whole separation between IoProcessor and IoService and where \
we manage closing/accepting queues. </div></li>
</ul>
<ul>
<li>session should not necessarily be associated with a processor.
<div class="vrm"><strong>vrm :</strong>
+1
</div></li>
</ul>
<ul>
<li>If a session is stateful, then we should attach the data to the channel instead \
of creating a map for that <div class="vrm"><strong>vrm :</strong>
Can you say more about that, where is the gain ?
</div>
<div class="ele"><strong>ele :</strong>
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. </div>
<div class="vrm"><strong>vrm :</strong>
So you want to trash all the session hashmap and just give access to the attachement \
of an Object at the NIO level ? </div></li>
</ul>
<ul>
<li>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 <div \
class="vrm"><strong>vrm :</strong> 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.
</div>
<div class="ele"><strong>ele :</strong>
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... \
</div></li> </ul>
<div class="ele"><strong>ele :</strong>
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.
</div>
<ul>
<li>It should be possible to close a session on a specific message reception, \
without having to add a listener for that <div class="ede"><strong>ede :</strong> use \
case ? </div> <div class="ele"><strong>ele :</strong>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</div></li> \
</ul>
<h2><a name="MINA3.0design-codec"></a>codec</h2>
<ul>
<li>we don't have stateful or stateless codecs. We should distinguish the two kinds \
of codec someone can use. <div class="vrm"><strong>vrm :</strong>
+1
</div></li>
<li>we should define a collection of existing codecs
<div class="vrm"><strong>vrm :</strong>
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. </div>
<div class="ele"><strong>ele :</strong>
They are very different. The codec should define not only the encoder and the \
decoder, but the associated POJOs. </div></li>
<li>as we can handle more than one protocol, we must add a demuxingCodec which point \
to the next filter, conditionally <div class="vrm"><strong>vrm :</strong>
Here the graph ? :)
</div>
<div class="ele"><strong>ele :</strong>
Yes
</div></li>
</ul>
<h2><a name="MINA3.0design-Buffer"></a>Buffer</h2>
<ul>
<li>We should not wrap ByteBuffer into our own IoBuffer class. We should have a list \
of ByteBuffers instead, containing all the ByteBuffers. <div class="vrm"><strong>vrm \
:</strong> And some extended Stream interface for manipulation.
</div></li>
<li>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)</li> \
</ul>
<h2><a name="MINA3.0design-General"></a>General</h2>
<ul>
<li>offer a NIO 2.0 library
<div class="vrm"><strong>vrm :</strong>
Well it's going to be soon mandatory :)
</div></li>
<li>Use real Future implementation</li>
<li>Support Multicast</li>
<li>Create a benchmark suite</li>
</ul>
<p>This is just a starting point ...</p>
<div class="vrm"><strong>vrm :</strong>
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.
</div>
<h2><a name="MINA3.0design-Debuggingtool"></a>Debugging tool</h2>
<div class="vrm"><strong>ashish:</strong> We need debugging tool for easy debugging \
of MINA Apps. We can explore VisualVM plugin for achieving the same or a standalone \
UI.</div>
!http://www.gliffy.com/pubdoc/2060745/L.png|border=1!
Captured some initial thoughts on the tool. JMX based interface would be the most \
preferred choice
<h2><a name="MINA3.0design-Notes"></a>Notes</h2>
<ul>
<li>Linux seems to be capping the connection at the upper bound when the connection \
starts</li> </ul>
<h2><a name="MINA3.0design-References"></a>References</h2>
<ul>
<li><a href="http://www.ibm.com/developerworks/linux/library/l-hisock.html" \
class="external-link" rel="nofollow">How buffer settings affect performance</a></li> \
<li><a href="http://www.ibm.com/developerworks/library/j-zerocopy/" \
class="external-link" rel="nofollow">Zerocopy</a></li> </ul>
</div>
<div id="commentsSection" class="wiki-content pageSection">
<div style="float: right;">
<a href="https://cwiki.apache.org/confluence/users/viewnotifications.action" \
class="grey">Change Notification Preferences</a> </div>
<a href="https://cwiki.apache.org/confluence/display/MINA/MINA+3.0+design">View \
Online</a> |
<a href="https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=120101&revisedVersion=20&originalVersion=19">View \
Changes</a> |
<a href="https://cwiki.apache.org/confluence/display/MINA/MINA+3.0+design?showComments=true&showCommentArea=true#addcomment">Add \
Comment</a> </div>
</div>
</div>
</div>
</div>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic