[ 
https://issues.apache.org/jira/browse/GEODE-8506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17198420#comment-17198420
 ] 

ASF GitHub Bot commented on GEODE-8506:
---------------------------------------

bschuchardt commented on a change in pull request #5525:
URL: https://github.com/apache/geode/pull/5525#discussion_r491045634



##########
File path: 
geode-core/src/main/java/org/apache/geode/internal/net/BufferPool.java
##########
@@ -295,19 +302,48 @@ void releaseBuffer(BufferPool.BufferType type, ByteBuffer 
buffer) {
   /**
    * Releases a previously acquired buffer.
    */
-  private void releaseBuffer(ByteBuffer bb, boolean send) {
-    if (bb.isDirect()) {
-      BBSoftReference bbRef = new BBSoftReference(bb, send);
-      if (bb.capacity() <= SMALL_BUFFER_SIZE) {
+  private void releaseBuffer(ByteBuffer buffer, boolean send) {
+    if (buffer.isDirect()) {
+      buffer = getPoolableBuffer(buffer);
+      BBSoftReference bbRef = new BBSoftReference(buffer, send);
+      if (buffer.capacity() <= SMALL_BUFFER_SIZE) {
         bufferSmallQueue.offer(bbRef);
-      } else if (bb.capacity() <= MEDIUM_BUFFER_SIZE) {
+      } else if (buffer.capacity() <= MEDIUM_BUFFER_SIZE) {
         bufferMiddleQueue.offer(bbRef);
       } else {
         bufferLargeQueue.offer(bbRef);
       }
     } else {
-      updateBufferStats(-bb.capacity(), send, false);
+      updateBufferStats(-buffer.capacity(), send, false);
+    }
+  }
+
+  /**
+   * If we hand out a buffer that is larger than the requested size we create a
+   * "slice" of the buffer having the requested capacity and hand that out 
instead.
+   * When we put the buffer back in the pool we need to find the original, 
non-sliced,
+   * buffer. This is held in DirectBuffer in its "attachment" field, which is 
a public
+   * method, though DirectBuffer is package-private.
+   */
+  @VisibleForTesting
+  public ByteBuffer getPoolableBuffer(ByteBuffer buffer) {

Review comment:
       Subclassing ByteBuffer isn't possible due to the class having final 
methods.  Introducing a new class seems desirable but would affect a lot of 
code and this needs to be backported to 1.12 and 1.13 support branches.  In 
such cases it's best to keep code changes to a minimum.




----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


> BufferPool returns byte buffers that may be much larger than requested
> ----------------------------------------------------------------------
>
>                 Key: GEODE-8506
>                 URL: https://issues.apache.org/jira/browse/GEODE-8506
>             Project: Geode
>          Issue Type: Improvement
>          Components: membership
>            Reporter: Bruce J Schuchardt
>            Assignee: Bruce J Schuchardt
>            Priority: Major
>              Labels: pull-request-available
>
> BufferPool manages several pools of direct-memory ByteBuffers.  When asked 
> for a ByteBuffer of size X you may receive a buffer that is any size greater 
> than or equal to X.  For users of this pool this is unexpected behavior and 
> is causing some trouble.
> MessageStreamer, for instance, performs message "chunking" based on the size 
> of a socket's buffer size.  It requests a byte buffer of that size and then 
> fills it over and over again with message chunks to be written to the socket. 
>  But it does this based on the buffer's capacity, which may be much larger 
> than the expected buffer size.  This results in incorrect chunking and 
> requires larger buffers in the receiver of these message chunks.
> BufferPool should always return a buffer that has exactly the requested 
> capacity.  It could be a _slice_ of a pooled buffer, for instance.  That 
> would let it hand out a larger buffer while not confusing the code that 
> requested the buffer.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to