[
https://issues.apache.org/jira/browse/THRIFT-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17118910#comment-17118910
]
Duru Can Celasun commented on THRIFT-5214:
------------------------------------------
[~fishywang] 0.14 isn't a concern right now so we can wait a few days. Can you
share what exactly went wrong? Increased latency, error rates?
Before merging I've played with your PR locally and it seemed fine. We only
have Go servers, not clients at work so there is no real traffic I can test it
on.
> 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)
