thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (THRIFT-3854) allow users to clear read buffers
Date Thu, 26 Jan 2017 20:49:24 GMT


ASF GitHub Bot commented on THRIFT-3854:

Github user jsirois commented on a diff in the pull request:
    --- Diff: lib/java/src/org/apache/thrift/transport/ ---
    @@ -123,6 +123,12 @@ public void consumeBuffer(int len) {
    +  public void clear() {
    +    if (readBuffer_ != null) {
    --- End diff --
    `readBuffer_` is declared `private TMemoryInputTransport readBuffer_ = new TMemoryInputTransport(new
byte[0]);` and never re-assigned in this class. Unless there is known code re-assigning via
reflection, this should just be promoted to final and all the null checks - like the one added
here - dispensed with.

> allow users to clear read buffers
> ---------------------------------
>                 Key: THRIFT-3854
>                 URL:
>             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

View raw message