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" <elecha...@gmail.com> 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<MessageDecorator<? extends Message>> container ) > throws DecoderException > { > ... > } > } > > > public class LdapProtocolDecoder implements ProtocolDecoder > { > public void decode( IoSession session, IoBuffer in, > ProtocolDecoderOutput out ) throws Exception > { > List<Message> decodedMessages = new ArrayList<Message>(); > 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<Type, Handler> > 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 >