You mean the AHC codec in the Geronimo sandbox? AFAIK, the response decoder in our repository is not using CumulativeProtocolDecoder.
2008-03-10 (월), 19:17 -0700, Sangjin Lee 쓰시길: > 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/ -- Trustin Lee - Principal Software Engineer, JBoss, Red Hat -- what we call human nature is actually human habit -- http://gleamynode.net/
signature.asc
Description: This is a digitally signed message part
