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