DataBuffer should offer restricted access to underlying ByteBuffer #29943
Labels
in: core
Issues in core modules (aop, beans, core, context, expression)
type: enhancement
A general enhancement
Milestone
Netty 4's
ByteBuf
allowed for direct, unrestricted access of the underlyingByteBuffer
(s) through thenioBuffers
method. This allowed for integration withByteBuffer
-based APIs (including java.nio), but also opened the door for memory leaks. Spring 5 exposednioBuffer
throughDataBuffer::asByteBuffer
.Netty 5's
Buffer
does not allow unrestricted access to the underlyingByteBuffer
. As a consequence, in Spring 6DataBuffer::toByteBuffer
was introduced. This method makes a copy, and is implemented inNetty5DataBuffer::toByteBuffer
usingBuffer::copyInto
.In various places throughout Spring Framework 6, including frequently invoked code such as codecs and transports,
DataBuffer::toByteBuffer
is used to integrate withByteBuffer
-based APIs. This means that buffers are copied more frequently than in Spring 5, even in other server environments than Netty. See #29889.Netty 5's
Buffer
does allow restricted access to the underlyingByteBuffer
, throughBuffer::forEachComponent
. Memory leaks are negated by only allowing access to the raw memory for the scope of the returned iterator, like so:We should expose Netty 5's
Buffer::forEachComponent
through a method inDataBuffer
, implement that method in Netty 4 usingByteBuf::nioBuffers
, and write an implementations forDefaultDataBuffer
.The text was updated successfully, but these errors were encountered: