[
https://issues.apache.org/jira/browse/THRIFT-5069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17018155#comment-17018155
]
Yuxuan Wang commented on THRIFT-5069:
-------------------------------------
[~dcelasun] Do you think it makes sense to provide (additional) pooled version
of TSerializer and TDeserializer from thrift's go library directly? Currently
TSerializer and TDeserializer are not thread safe (we were bitten by it once,
someone tried to use a single TSerializer for everything, ended up with corrupt
data everywhere), so providing a thread safe (by using a resource pool
underneath) version might make sense? I can either reuse this ticket or create
a new one :)
> 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
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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)
