[
https://issues.apache.org/jira/browse/THRIFT-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15840422#comment-15840422
]
ASF GitHub Bot commented on THRIFT-3854:
----------------------------------------
Github user jsirois commented on a diff in the pull request:
https://github.com/apache/thrift/pull/1081#discussion_r98087986
--- Diff:
lib/java/src/org/apache/thrift/transport/TFastFramedTransport.java ---
@@ -164,6 +166,10 @@ public void consumeBuffer(int len) {
readBuffer.consumeBuffer(len);
}
+ public void clear() {
+ readBuffer = new
AutoExpandingBufferReadTransport(initialBufferCapacity, 1.5);
--- End diff --
It would be nice to share the initialization code on line 110 above in the
constructor - consider factoring out a factory or calling reset from the
constructor to initialize `readBuffer` for the 1st time.
> allow users to clear read buffers
> ---------------------------------
>
> Key: THRIFT-3854
> URL: https://issues.apache.org/jira/browse/THRIFT-3854
> Project: Thrift
> Issue Type: Improvement
> Components: Java - Library
> Reporter: Chris Lockfort
> Priority: Minor
> Attachments: thrift-3854-clearable-read-buffers.patch
>
>
> My use case (which I believe many others would share):
> - I have a large number of Thrift connections in a connection pool
> - Upon return of the used connection to the pool I would like to eagerly
> clean up the read buffer because I know it will not be used again until the
> connection is checked out and a new read puts a new buffer in its place.
> - Eagerly clearing the read buffers of idle connections saves a considerable
> amount of heap memory in my application, vs. having all of the idle
> connections keep all of their read buffers allocated.
> - Currently, it looks like someone thought about this and there is a
> TMemoryInputTransport#clear() , but it isn't callable from people with a
> TFramedTransport which uses a TMemoryInputTransport for its read buffer
> (unless you count doing gross and brittle reflection magic).
> I've included a patch, but I'm very flexible / open to opinions of how
> someone more familiar to this project would want to implement a feature like
> this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
