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 Sun, 11 Jun 2006 15:56:37 GMT
On 6/10/06, Niklas Therning <niklas@trillian.se> wrote:
>
> Trustin Lee wrote:
> > The separation between IoHandler and protocol codec loses its meaning if
> > IoHandler takes care of the codec's state.  That's why I don't want
> > IoHandler affect any state of decoder or encoder.  And as I mentioned,
> the
> > state of the decoder might not change immediately in case that there's a
> > thread pool filter between the protocolcodecfilter and IoHandler.
>
> When the client sends the DATA command I do the following in my IoHandler:
>
> session.setAttribute(CommandProtocolDecoder.DATA_MODE);
> session.write(new OkResponse());
>
> From here on my CommandProtocolDecoder will forward the received
> ByteBuffers without doing any special processing. Now consider what
> would happen if the IoHandler responds with a negative response instead.
> In that case my CommandProtocolDecoder shouldn't switch to data mode but
> should continue to decode as usual. If I'm not allowed to control this
> from my IoHandler my decoder and encoder would both have to be aware of
> (at least partially) where in the protocol flow the current session is.
> Of course my IoHandler also needs to now this so instead of my IoHandler
> being the only one with any knowledge of where we are in the flow all of
> them have to keep track of what has happened previously in order to know
> what to do next.


You are correct.  Sorry for stating a wrong point.

> My suggestion is still to provide a switchable encoder/decoder.
> > TokenSelectorStream in ANTLR shows a nice example regarding this
> pattern:
> >
> > http://www.antlr.org/doc/streams.html#lexerstates
> >
> > For example:
> >
> > SwitchableProtocolDecoder d = new SwitchableProtocolDecoder();
> > d.register("default", new DefaultProtocolDecoder());
> > d.register("attachment", new AttachmentDecoder());
> > d.push("default");
> >
> > ...
> > if (timeToDecodeAttachment) d.push("attachment");
> > ...
> > if (finishedDecodingAttachment) d.pop();
> > ...
>
> I think this is a very nice idea. Would my IoHandler control the pushes
> and pops? In that case you would still need the flush() method in PDO,
> right? Otherwise you cannot switch decoder in between two messages if
> they arrive in the same buffer. And the issue with using a
> ThreadPoolFilter between the ProtocolCodecFilter and IoHandler would
> still remain. Or am I missing something?


You're right.  This selector pattern is not necessarilly related with the
issue you raised.  It is just a good-to-have class.

Please remember that the only change to MINA I'm suggesting is to
> introduce the flush() method in PDO so that I could control flushes from
> within my decoder. The PDO doesn't even have to be pluggable.


Ahh didn't we have a flush() method in ProtocolDecoderOutput?  Let's add it
then! :)

Thanks,
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

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