Le 12/31/12 7:55 AM, Julien Vermillard a écrit :
> Hi,
>
> Since few year, I stopped to use the MINA ProtocolCodecFilter and
> associated stuff (CumulativeCodec..). for implementing my own codec
> independent of MINA.
>
> it's just a service consuming ByteBuffer and pushing decoded POJO in a
> callback. The point is to be independent of MINA for example, parse & save
> files using the codec, or simply implement an HTTP version of the transport
> using old style servlet.
>
> Basically a decoder looks like : https://gist.github.com/4417934
> One is instantiated by session.
>
> I'm quite happy with that and I think we should not port the old
> ProtocolCodeFilter to MINA 3.0 and replace it with a independent MINA async
> decoder framework (consuming BB, accumulating if needed and producing pojo).
It sounds a reasonnable proposal.
If we think about it, decoding is not part of a filter chain : it
introduces a change of data type being passed from one filter to the
other, and if we have to cumulate data, we will just stop processing the
incomming data in the middle of the chain, the handler being unaware of
this fact.
Julien's proposal seems way better : the Handler would have a common
interface for encoding and decoding, used as a service when a
MessageReceived or a Write events are to be processed. This way, the
handler is fully in charge of all the aspects of the data processing,
including the accumulation of data.
It won't either eliminate the existence of pre-written codec, like the
HttpCodec, or the Textline codec. We can even think about a chain of
codecs : one codec depends on the result of the previous codec.
As far as I can tell, changing MINA this way will not impact ApacheDS,
even if we are using a DemuxIoHandler (the handler called depends on the
received message) : I don't see such a handler as a simplification over
a simple switch...
Keep in mind that the exisiting MINA logic depends on an idea which is
10 years old : SEDA, and has not proven any advantage against simpler
implementations. It's also important to notice that SEDA implies that
each process part communicates with the next process (read : filter) by
the use of queues. This is highly costly and memory consuming. I'm not
sure that SEDA has anything to do with MINA implementation anwyay...
On more thing : the current codec supposes that we pass a callback which
is called as soon as something has been decoded. This make the code
extremely complicated to debug. I'd rather have a system where we can
loop on the decoder, until it produces nothing. In other words, instead
of having something like :
void myCallback( IoSession session, Object message ) {
// Do something
}
void decode( IoSession session, ByteBuffer buffer, callback ) {
// Decode and call the callback
}
void messageReceived( IoSession session, ByteBuffer buffer ) {
decode( session, myCalback );
...
}
I would prefer something like :
Object decode( IoSession session, ByteBuffer buffer ) {
// Decode
return decoded;
}
void messageReceived( IoSession session, ByteBuffer buffer ) {
while ( ( Object decoded = decode( session ) ) != null ) {
// Do something
}
}
>
> Julien
>
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
