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

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

bschuchardt merged pull request #5525:
URL: https://github.com/apache/geode/pull/5525


   


----------------------------------------------------------------
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