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
