Well, the response decoder in the AHC codec happens to be using the
cumulative decoder. :)
Sangjin
On Mar 10, 2008, at 7:14 PM, 이희승 "(Trustin Lee)"
<[EMAIL PROTECTED]> wrote:
Yes, it's underivable by its design. If a user calls slice() or
duplicate() on the buffer received from CumulativeProtocolDecoder, the
buffer cannot be expanded anymore. However, CumulativeProtocolDecoder
caches it expecting it to be always (auto-)expandable, so any
derivation
operation will cause CumulativeProtocolDecoder to throw an exception.
One solution to this problem is to modify CumulativeProtocolDecoder to
check if the buffer became underivable before every put() operation
and
allocate new auto-expandable buffer when it became underivable.
For now, CumulativeProtocolDecoder is the only class that uses
UnderivableBuffer and I can't think of any other possible usage right
now, so we could get rid of it together with my proposed change.
How does it sound?
2008-03-10 (월), 16:01 -0700, Sangjin Lee 쓰시길:
I've seen this problem in the past, and I'm seeing it again...
If one extends the CumulativeDecoder and finds that there is not
enough data
in the buffer, one returns false on doDecode() so mina can collect
more
data. However, it seems that CumulativeDecoder puts the last
remaining
bytes from the decode into an UnderivableBuffer and stores it in the
session. When it gets more data later, the data is added to this
session
buffer, and the CumulativeDecoder subclass gets to it.
The problem is, things like slice() and duplicate() on an
UnderivableBuffer
throw an exception. Therefore, your cumulative decoder that does
slice()
will result in an exception. Is this by design? Should you write
your
cumulative decoder in such a way one should never call slice()?
This is
somewhat unexpected because Mina 1.1 did not have such a restriction.
The example class named CrLfTerminatedCommandLineDecoder mentioned
in the
javadoc of CumulativeDecoder also uses IoBuffer.slice(). I wrote a
quick
test that exercises this class, and as expected, I get an
UnsupportedOperationException saying buffer derivation is disabled.
Any thoughts on this? Does one need to find a way to use the
CumulativeDecoder that avoids these methods?
Thanks,
Sangjin
--
Trustin Lee - Principal Software Engineer, JBoss, Red Hat
--
what we call human nature is actually human habit
--
http://gleamynode.net/
