[
https://issues.apache.org/jira/browse/THRIFT-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17118942#comment-17118942
]
Yuxuan Wang commented on THRIFT-5214:
-------------------------------------
We have two upstream servers, one in go and one in java. The go one is kinda
what we expected, that the latency went slightly up, and didn't cause much
problems. For the java one, the latency went way up and almost all requests
timed out.
We do have both upstream servers in our staging setup and we didn't see the
same problem while running it on staging, though.
> go: Implement connection check in TSocket
> -----------------------------------------
>
> Key: THRIFT-5214
> URL: https://issues.apache.org/jira/browse/THRIFT-5214
> Project: Thrift
> Issue Type: Improvement
> Components: Go - Library
> Reporter: Yuxuan Wang
> Priority: Major
> Fix For: 0.14.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> The first issue described in [this GitHub engineering blog
> article|https://github.blog/2020-05-20-three-bugs-in-the-go-mysql-driver/] is
> also an issue when we use thrift client pools. We implemented a thrift client
> pool by checking client's TTransport.IsOpen before using that client, and
> also added (arbitrary) TTL to the clients to avoid using clients that's been
> opened for too long, but we still occasionally get broken pipes and
> unexpected EOF errors when using those clients. I think implementing the same
> connection check described by that article in TSocket.IsOpen (and/or when try
> to read 0 byte from TSocket.Read) would greatly help the situation.
> But there are a few limitations of the connection check implementation, and
> I'm not sure how acceptable are they in the thrift library:
> 1. It only works on non-windows systems (so for windows we'll have to
> fallback to the old IsOpen implementation, I guess?)
> 2. It requires go 1.9+, what's thrift library's minimal go version supported?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
