Hi Niklas, On 4/26/06, Niklas Therning <[EMAIL PROTECTED]> wrote:
Trustin Lee wrote: > On 3/27/06, Niklas Therning <[EMAIL PROTECTED]> wrote: > >>In protocols like SMTP when there are simple line-based commands >>intermixed with raw data (mail data) there are also great opportunities >>for optimization if you write your own codec filter. I've implemented my >>own DecoderFilter which can operate in "data mode". When not in data >>mode the filter will act more or less like an ordinary ProtocolDecoder, >>copying the received buffer to an autoexpanding buffer, decode SMTP >>commands and pass them on to the next filter. When in data mode however >>the filter will simply forward the buffers as they are received without >>any copying (in most cases). >> >>I guess this could be achieved with the MINA codec package but not >>without some tweaking and not as efficiently. Please let me know if I'm >>wrong. >> >>I wouldn't mind adding this filter to MINA if anyone is interested. > > > > It would be nice if we can generalize this behavior. We could then switch > arbitrary set of filters in runtime fairly easily. WDYT? > > Trustin I think DIRMINA-201 solves the efficiency issue I was referring to. The only thing that would have to change to make ProtocolCodecFilter suit my needs is that SimpleProtocolDecoderOut shouldn't queue messages but rather forward them to the nextFilter right away as they are written. Then my IoHandler would be able to instruct my Decoder instance to change its state and decode differently depending on what the previous message was.
If we directly call the IoHandler.messageReceived() when we call ProtocolDecoderOut.write(), any exceptions raised by the handler can interrupt the decoding process. SimpleProtocolDecoderOut.write() could catch the exception but I think it cannot fire exceptionCaught event correctly because it cannot access AbstractIoFilterChain without breaking the OO design. Moreover, we cannot guarentee that IoHandler.messageReceived() is executed in the same thread with ProtocolDecoderOut.write() because there can be an extra thread pool between the codec and the handler. Is it a problem for you to change the decoder state in the decoder itself? Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP key fingerprints: * E167 E6AF E73A CBCE EE41 4A29 544D DE48 FE95 4E7E * B693 628E 6047 4F8F CFA4 455E 1C62 A7DC 0255 ECA6
