Demuxingiohandler .. what a moronic piece of code, it s sure you
should not depend on that. In place of switch case you should use
polymorphism (visitor pattern fits).
BTW the OutOfOrderExecutor Will process your two messages in two // threads.
--
Julien Vermillard
Le 12 janv. 2013 à 08:09, "Emmanuel Lécharny" a écrit :
> Hi !
>
> I did some experiment with the LDAP codec today. It's not exactly easy
> to check if it can work safely with MINA 3, as it's almost impossible to
> write a standalone LDAP codec in MINA without doing some huge
> modifications in the LDAP API code.
>
> I think it should be done the other way out : the LDAP API code should
> be made network agnostic, so that we can write a mina project depending
> on the LDAP API, not the other way out. Currently, the LDAP API depends
> on MINA 2 heavily, and I'd like to make it depend on whatever network
> layer we have (be it MINA 2, MINA3 or even Netty).
>
> So I will have to rework the LDAP API code to use a factory to
> instanciate the selected network layer.
>
>
> Otherwise, the current LDAP API codec interface is pretty simple :
>
> public class LdapDecoder
> {
>/**
> * Decodes a PDU from an input stream into a Ldap message container.
> We can only
> * decode one complete message.
> *
> * @param in The input stream to read and decode PDU bytes from
> * @return return The decoded message
> */
>public Message decode( InputStream in,
> LdapMessageContainer> container )
>throws DecoderException
>{
>...
>}
> }
>
>
> public class LdapProtocolDecoder implements ProtocolDecoder
> {
>public void decode( IoSession session, IoBuffer in,
> ProtocolDecoderOutput out ) throws Exception
>{
>List decodedMessages = new ArrayList();
>ByteBuffer buf = in.buf();
>
>decode( buf, messageContainer, decodedMessages );
>
>for ( Message message : decodedMessages )
>{
>out.write( message );
>}
>}
> }
>
> and the very same for the encoder.
>
> The decode( buf, messageContainer, decodedMessages ) call just deal with
> the pure LDAP decoding, and the storage of a state if the incoming data
> don't contan a full message (this is a stateful decoder).
>
> As is, there is no reason for the LDAP decoder to be incompatible with
> MINA 3, except that we have to find another way to handle decoded
> messages (currently, we use a ProtocolDecoderOutput intermediate
> structure, which in fact is just a callback storing the decoded messages
> into a queue, a solution I frankly don't like...)
>
> Would we use MINA 3 in ApacheDS, there is one thing we will need to add
> in MINA 3, and one thing we will have to modify in ApacheDS :
> o ApacheDS depends on the MINA2 DemuxingIoHandler interface, which does
> no exist in MINA3. This interface role is to redirect each message to a
> dedicated handler. For that purpose, we register in a Map
> each decoded message type and the associated MessageHandler. IMO, this
> is a total waste of CPU : a decent switch based on a message type would
> perfectly do the job, and more efficiently. I'll work on this part in
> ApacheDS to remove this dependency.
> o We need to accept two messages for the same session, and be able to
> process them in two different threads. In order to do that in MINA 2, we
> have added an OrderedThreadPollExecutor after the LdapDecoder. In MINA
> 3, this will be slighty different : the executor will be an
> InOrderHandlerExecutor, but that requires we add a codec Filter in the
> chain.
>
> In other words, we can't put the decoder *after* the handler, it must be
> executed before. This is not an issue hough.
>
> Frankly, I do think that I can have ApacheDS working based on MINA 3 in
> probably one or two days, no more. It will most certainly not require
> any modification in MINA3 whatsoever.
>
> Performance wise, the last time I conducted some performance tests on
> ApacheDS (with MINA2), I was able to reach 13 000 lookup per second (ie,
> we were able to send 13000 search request and send back 13000
> SearchResultEntry and 13000 SearchResultDone messages per second.). The
> exact same benchmark (ie, a lookup) done without the network layer
> exhibit a bare performance of around 60 000 requests per second, 5 times
> faster.
>
> With MINA 3 being 50% faster than MINA 2, I do expect we will be able to
> reach 20 000 requests per second on my laptop. The real problem will be
> to be able to start enough client to simulate the load :)
>
> Ok, now, time to shape a working prototype !
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
