mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Fisk"...@lastbamboo.org>
Subject Re: Tutorial on ProtocolCodecFilter, state and threads
Date Sat, 28 Jul 2007 20:40:50 GMT
Belated thanks!

-Adam


On 7/16/07, Maarten Bosteels <mbosteels.dns@gmail.com> wrote:
>
> Adam, Trustin,
>
> I added your comments to the tutorial.
>
> Maarten
>
> On 7/16/07, Trustin Lee <trustin@gmail.com> wrote:
> >
> > Hi Adam,
> >
> > On 6/23/07, Adam Fisk <a@lastbamboo.org> wrote:
> > > That's also how AsyncWeb is implemented, incidentally, with a separate
> > > encoder and decoder stored as a session attribute for each
> session.  The
> > > code for HttpServerCodecFactory does this with the following:
> > >
> > >   public ProtocolDecoder getDecoder() throws Exception {
> > >     (topLevelState creation omitted)
> > >     return new StateMachineProtocolDecoder(topLevelState);
> > >   }
> > >
> > >   public ProtocolEncoder getEncoder() throws Exception {
> > >     return new OneShotHttpResponseEncoder();
> > >   }
> > >
> > > This seems preferable to me, honestly, as it's just less complicated.
> >
> > Yes, it is a matter of preference and the characteristic of protocols.
> > I also prefer to create a new decoder per session.  However, the
> > decoder of some protocols doesn't need to store any state information,
> > so it might be more suitable to use the same decoder instance for
> > multiple sessions (e.g. UDP).
> >
> > HTH,
> > Trustin
> >
> > > On 6/22/07, Adam Fisk <a@lastbamboo.org> wrote:
> > > >
> > > > Hi Maarten-
> > > >
> > > > Thanks for the link to that discussion thread.  It seems like
> there's
> > > > quite a bit of confusion on this point, though.  The thread really
> > didn't
> > > > reach a common consensus in my reading of it.
> > > >
> > > >
> > > > > Indeed, I want thread-2 to see the changes made by thread-1.
> > > > > But without synchronization, there is no such guarantee.
> > > >
> > > >
> > > > Right, but the tutorial snippet says "MINA ensures that there will
> > never
> > > > be more than one thread simultaneously executing the decode()
> function
> > for
> > > > the same IoSession".  For that to be true, there's gotta be some
> > > > synchronization somewhere.  I decided to dig into the code a little
> > bit for
> > > > the 1.1.0 branch, and indeed ProtocolCodecFilter has the following:
> > > >
> > > >         try
> > > >         {
> > > >             synchronized( decoderLock )
> > > >             {
> > > >                 decoder.decode( session, in, decoderOut );
> > > >             }
> > > >         }
> > > >
> > > > With the code above, the changes made by thread-1 on the decoder
> *are
> > > > guaranteed to be seen by thread-2*.  Now, I realize this is an
> > > > implementation detail of 1.1.0, but the tutorial description above
> > seems
> > > > to be relying on that detail.  So it seems like it should be totally
> > fine to
> > > > have a ProtocolCodecFactory that returns a new decoder on each
> > getDecoder
> > > > call (effectively one decoder per session).  I still don't see the
> > > > disadvantage of doing this.
> > > >
> > > > It certainly seems less complicated that way!
> > > >
> > > > Thanks again for your patience Maarten.  Seems like a key point we
> > should
> > > > all be clear on, so that's why I'm trying to dig a little deeper
> here.
> > > >
> > > > -Adam
> > > >
> > > >
> > >
> >
> >
> > --
> > what we call human nature is actually human habit
> > --
> > http://gleamynode.net/
> > --
> > PGP Key ID: 0x0255ECA6
> >
>

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