On May 1, 2006, at 3:01 PM, Frederic Soulier 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?
I'm not using the Demux stuff. My decoder extends CumulativeProtocolDecoder, and the work is done in the doDecode implementation.
My decoder works like this:* For each message type, there is a decoder that can decode the message. It knows nothing about there being a type/length code in the ata * There exists a "MyProtocolDecoder" (which is a CumulativeProtocolDecoder) that has each of the above decoders registered with it with a numeric code. * When MyProtocolDecoder has a message's worth of data, it reads the type code, looks up the decoder, uses ByteBuffer.limit() to set the view to only the messgae, and passes that to the decoder that was looked up.
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.
Unless you add some sort of synchronization, it should be thread-safe and allow multiple concurrent invocations.
-pete -- (peter.royal|osi)@pobox.com - http://fotap.org/~osi
smime.p7s
Description: S/MIME cryptographic signature
