[
https://issues.apache.org/jira/browse/THRIFT-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17017719#comment-17017719
]
Yuxuan Wang commented on THRIFT-5069:
-------------------------------------
I just realized that for TDeserializer not calling Reset will not affect the
correctness. But when use it with a resource pool it does affect performance
because otherwise the buffer will just keep growing. So I think this is still
worth doing.
> Go: TDserializer is not resource pool friendly
> ----------------------------------------------
>
> Key: THRIFT-5069
> URL: https://issues.apache.org/jira/browse/THRIFT-5069
> Project: Thrift
> Issue Type: Improvement
> Components: Go - Library
> Reporter: Yuxuan Wang
> Priority: Major
>
> Currently TSerializer is resource pool friendly (see
> [here|https://github.com/reddit/baseplate.go/blob/7b73f185eacd319a018df85d683fb2c29b50e2a9/events/events.go#L105-L111]
> for an example), but TDeserializer is not. When putting a TDeserializer back
> into resource pool, some extra works need to be done:
> {code:go}
> defer func() {
> deserializer.Transport.(*thrift.TMemoryBuffer).Reset()
> deserializerPool.Put(deserializer)
> }()
> {code}
> If we change the type of TDeserializer.Transport to *TMemoryBuffer, and also
> call Transport.Reset() at the beginning of Read and ReadString (we already do
> both in TSerializer), it will make it more resource pool friendly.
> This will be a breaking change, though.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
