mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Trustin Lee" <trus...@gmail.com>
Subject Re: Switching codecs in runtime (Was: Removing synchronization on a ProtocolEncoder and a ProtocolDecoder)
Date Sat, 06 May 2006 11:13:25 GMT
Hi Niklas,

On 4/26/06, Niklas Therning <niklas@trillian.se> wrote:
> Trustin Lee wrote:
> > On 3/27/06, Niklas Therning <niklas@trillian.se> 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?

what we call human nature is actually human habit
PGP key fingerprints:
* E167 E6AF E73A CBCE EE41  4A29 544D DE48 FE95 4E7E
* B693 628E 6047 4F8F CFA4  455E 1C62 A7DC 0255 ECA6

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message