From: Bongjae Chang <carryel_at_korea.com>
Date: Wed, 13 May 2009 22:07:04 +0900

Hi,

I tried to use CacheableSelectionKeyHandler, but some problems were occurred when ProtocolParser's isExpectingMoreData() returned true.

In conclusion, CacheableSelectionKeyHandler#postProcess(SelectionKey key) didn't call super.postProcess( key ).

In CacheableSelectionKeyHandler.java
----
public void postProcess(SelectioKey key) {
    super.postProcess( key );
     ...
}
----

So WokerThread's detach() couldn't be called and the byteBuffer was recycled inadequately.

I know that ParserProtocolFilter saves the current thread's ByteBuffer and attaches the ThreadAttachment to SelectionKey if ProtocolParser's isExpectingMoreData() returns true. If detach() is not executed at this case, the remaining ByteBuffer can cause a parsing error.

When I reviewed the WorkerThread's detach() method, a question arised. Why does WorkerThread create new ByteBuffer in BYTE_BUFFER mode? The new ByteBuffer could become to be meaningless if the SelectionKey had a saved ByteBuffer, doesn't it?

In WorkerThreadImpl.java
----
public ThreadAttachment detach() {
    ...
    if((mode & Mode.BYTE_BUFFER) != 0 ) {
        createByteBuffer(true);
    }
}
----

And DefaultThreadPool already creates a ByteBuffer when it is equal to null in beforeExecute().

In DefaultThreadPool.java
----
protected void beforeExecute(Thread t, Runnable r ) {
    ((WorkerThreadImpl) t).createByteBuffer(false);
}
----

Perhaps, is it for the purpose of eliminating the dependency of the thread pool's impl?

If detach() is modified like this,
----
public ThreadAttachment detach() {
    ...
    if((mode & Mode.BYTE_BUFFER) != 0 ) {
        byteBuffer = null;
        //createByteBuffer(true);
    }
}
----

Could any side-effect be occurred?

Please advice me.

Thanks.

--
Bongjae Chang