[MINA 3] LDAP codec

[Emmanuel Lécharny <el...@gmail.com>]

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