garbled data passed in cumulation buffer for decode(), probably when data re-transmission.

[huican ping]

Hello Trustin,

Thank you very much for your reply.

Inside the getPipeline() method,
		pipeline.addLast("timeout", new receiveTimeoutHandler);
		pipeline.addLast("idle", new idleStateTimeoutHandler);
		pipeline.addLast("decoder", new AcmeDecoder();
		pipeline.addLast("encoder", new AcmeEncoder();

1:) Each time, when it is called, a new Decoder object will be create.
I assume it should be thread-safe for that cumulation
HeapChannelBuffer which is passed down from NioWorker. Am I right?

2:) further more, I noticed that even I set the Worker number to 1 at
the time of start:
		factory = new
NioServerSocketChannelFactory(Executors.newCachedThreadPool(),
Executors
				.newCachedThreadPool(), 1);
     On our internal project, I still saw the corrupted data, for
example, first 1024 bytes binary-zero, the remaining 42 byte are good.
Or vise vesa.
     I think for 1 Worker, there should only 1 WorkerThread, there
should be no others to change the buffer, is it right?

     Strange point:
           I created a standalone project for decoder, used the same
decoder/encoder and pipeline, and I never have any problem.

3:) Personaly, I think my Decoder should be fine. Then I used the
DelimiterBasedFrameDecoder from your source, and in our complicated
project, I also saw the bad data.

3:) Our internal project runs as a single java process, and it has
lots of JNI calls though.

Do you have any other insights?

Thanks
Ping

On Fri, Sep 25, 2009 at 2:13 AM, Trustin Lee (이희승) <trustin at gmail.com> wrote:
>
> It will be a problem if messageReceived() is called by different
> threads at the same time.  However, it does not happen because the
> decoder is places before ExecutionHandler or ExecutionHandler uses
> OrderedMemoryAwareThreadPoolExecutor.  If other executor is used and
> the decoder is placed after the ExecutionHandler, FrameDecoder will
> surely fail, but the failure should be very easy to reproduce.