This is interesting. In my implementation I just have
one decoder. So if I needed I could add multiple
decoders and in my first decoder when I
ProtocolDecoderOutput.write() my decoded packet it
will be sent to next decoder and not my
IoHandlerAdapter. Is this correct?

Thanks, S.D.

--- Frederic Soulier <[EMAIL PROTECTED]>
wrote:

> 
> On 1 May 2006, at 19:43, peter royal wrote:
> > I think so :) .. This is more akin to what I've
> implemented in my  
> > project. I'm using the ProtocolCodecFilter when a
> Decoder that  
> > reads the message type and length, and once it is
> all there,  
> > forwards the buffer to another decoder.
> 
> Ok so a primary decoder just keep saying NEED_DATA
> until a complete  
> message is ready.
> When you write "forwards the buffer to another
> decoder" do you mean a  
> MINA decoder?
> Aren't the decoder in the chain called
> automatically?
> 
> 
> 
> >> Also ultimately the messages will be processed by
> >>    public void messageReceived(IoSession session,
> Object message)
> >> in my IoHandler
> >> Is it ok to have long running transactions in
> there?
> >
> > That's up to you and what your application is
> doing. If you're  
> > using JTA and can suspend/resume a transaction,
> that might be ideal  
> > (you could do this in an IoFilter).
> >
> > Just make sure that transaction state is not
> stored in a  
> > ThreadLocal, because subsequent requests for the
> same connection  
> > are not guaranteed to occur on a particular
> thread. (A JTA suspend/ 
> > resume will accomplish this)
> 
> I think I used the wrong term here (i.e. long
> running). I meant to  
> ask if the IoHandler messageReceived method is going
> to be a point of  
> contention.
> 
> 
> 
> >> [Logging issue]
> >> Finally I keep getting the warning from Log4j
> (log4j:WARN No  
> >> appenders could be found for logger) and I'm
> baffled as to why it  
> >> does that.
> >
> > dunno, I use jdk14 logging :)
> 
> Ah damn :)
> 
> Thx.
> 
> --
> Frederic P. Soulier
> OpenPGP key available on http://pgpkeys.mit.edu/
> 1024D/BA6700ED   49A6 8E8E 4230 8D41 1ADE  B649 3203
> 1DD2 BA67 00ED
> 
> 

Reply via email to