[
https://issues.apache.org/jira/browse/THRIFT-4624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16602614#comment-16602614
]
ASF GitHub Bot commented on THRIFT-4624:
----------------------------------------
djnym commented on issue #1585: THRIFT-4624: Fix refc binary leak
URL: https://github.com/apache/thrift/pull/1585#issuecomment-418246218
The code seems reasonable, but I'm wondering of the need. Do you actually
see refc binary leakage? I could maybe see that happen if you have long lived
connections, from which you subtract a smallish portion of the binary from a
much larger thrift object and pass it around, but I'm not totally certain. Is
there a case where you are actually seeing this leakage occuring? @k32 Have
you checked out https://github.com/openx/ox-thrift which @dhull wrote? It uses
the ranch acceptor pool instead of the standard server and is a complete
rewrite of the message encoding/decoding. It's about 5-10x faster at
encoding/decoding, so it's an improvement. The only way to make it faster
would be to rewrite the compiler which @dhull has looked at but not done (the
idea would be to generate a custom module for encoding/decoding instead of the
generic structures which then get interpreted, this should lead to even more
efficiency as you'd not have to go through an intermediate representation).
Anyway, maybe David will take a look at this, but I think it's probably fine to
merge. My only real comment would be that this appears to make the default
copying the binaries, which could be a surprise if people aren't expecting it
and are moving large thrift structures around. So it might be worthwhile to
document that somewhere, not sure where though.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on 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
> Refc binary leak in binary and compact protocols
> ------------------------------------------------
>
> Key: THRIFT-4624
> URL: https://issues.apache.org/jira/browse/THRIFT-4624
> Project: Thrift
> Issue Type: Improvement
> Components: Erlang - Library
> Reporter: something
> Priority: Major
>
> Pattern-matching on large (>64B) Erlang binaries merely produces slices of
> objects on the Refc heap. Therefore Thrift binary and compact protocols
> should clone all binaries they send to upper levels, otherwise there's a
> chance that transport-level messages will be never freed.
> Patch is underway.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
