Belated thanks!
-Adam
On 7/16/07, Maarten Bosteels <[EMAIL PROTECTED]> wrote:
>
> Adam, Trustin,
>
> I added your comments to the tutorial.
>
> Maarten
>
> On 7/16/07, Trustin Lee <[EMAIL PROTECTED]> wrote:
> >
> > Hi Adam,
> >
> > On 6/23/07, Adam Fisk <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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
> >
>
