[ http://issues.apache.org/jira/browse/DIRMINA-201?page=comments#action_12373228 ]
Niklas Therning commented on DIRMINA-201: ----------------------------------------- Yes, you're right. There will definitely be times when one wants to hold on to a buffer for a longer time. I've had a look at your patches and I think they look very good. I'm not sure why there was a copy in SocketIoProcessor. The only thing I can think of is that the number of bytes read doesn't necessarily have to be equal to the size of the read buffer (session.getReadBufferSize()). I don't think it matters since IIRC ByteBuffer.allocate() is free to return a buffer larger than the requested size anyway so the capacity of the copy isn't guaranteed to be exactly readBytes. > Make the CumulativeProtocolDecoder "slice compatible" > ----------------------------------------------------- > > Key: DIRMINA-201 > URL: http://issues.apache.org/jira/browse/DIRMINA-201 > Project: Directory MINA > Type: Improvement > Versions: 0.9.3 > Reporter: Robert Greig > Attachments: CumulativeProtocolDecoder.java, CumulativeProtocolDecoder.java, > CumulativeProtocolDecoder.java.diff, SocketIoProcessor.java, > SocketIoProcessor.java.diff > > There is a problem with using slice() along with the > CumulativeProtocolDecoder. > The problem is that the CPD does a compact() when it has completed the > attempt to decode the buffer, and then reuses the buffer. > If your decoder expects to be able to take a slice() of the buffer and use > that it will find the data gets corrupted by the next call to the > CumulativeProtocolDecoder. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
