Yes, but I think I need to consider more things like the changes in IoBuffer together for better solution.
2008-03-10 (월), 23:39 -0700, Sangjin Lee 쓰시길: > I might have misunderstood what you're proposing. Are you proposing to get > rid of the UnderivableBuffer, not the CumulativeDecoder? > Thanks, > Sangjin > > > On Mon, 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
