[
https://issues.apache.org/jira/browse/GEODE-6663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16834071#comment-16834071
]
Darrel Schneider commented on GEODE-6663:
-----------------------------------------
I made a pretty simple change in: 0430cf6d80c6398b57ac08002692369557760da7
that causes the direct ByteBuffer that is used in readAck to have a minimum
size of: getConduit().tcpBufferSize when NioPlainEngine is created.
It also consistently sets the receive buffer in Connection to this size instead
of trying to optimize it by having it be SMALL_BUFFER_SIZE.
With those two changes I no longer saw small direct ByteBuffers getting managed
by the Buffers class.
> conserve-sockets=false can cause buffer fragmentation
> -----------------------------------------------------
>
> Key: GEODE-6663
> URL: https://issues.apache.org/jira/browse/GEODE-6663
> Project: Geode
> Issue Type: Bug
> Components: messaging
> Reporter: Darrel Schneider
> Priority: Major
> Labels: performance
>
> When conserve-sockets is set to false it enables an optimization called
> direct ack. This optimization allows the reply message to be sent directly
> back to the requestor on the same socket it sent to request. But the way the
> reply is read (see Connection.readAck) can cause small direct ByteBuffer
> instances to be created and added to the queue in the Buffers class. These
> small buffers can then cause future allocations from the queue to be slower
> because the small ones are removed and and added back to the end of the queue.
> I think it would be better for readAck to allocate one of this fixed size:
> "this.owner.getConduit().tcpBufferSize" instead of basing it off of the reply
> message size.
> That would keep the all the ones in Buffers the same size.
> It is possible that the "inputBuffer" owned by Connection could be used. But
> Bruce had this warning regard it: "Be careful about using the Connection's
> input buffer. I had so much trouble with multi-threaded access to that
> buffer that I decided not to use it in MsgReader."
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
