[
https://issues.apache.org/jira/browse/THRIFT-5214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17124261#comment-17124261
]
Yuxuan Wang commented on THRIFT-5214:
-------------------------------------
We tried it again today and have to revert again. This is what we learnt so far:
1. Another go service with a python upstream thrift server has no problem using
the new code
2. Our go service has no problem using the new code communicating with another
upstream go service
3. After our go service ran the new code for a few min, all requests to a java
upstream thrift server start to time out
So the problem has been narrowed to the jave upstream server, I think that left
us 3 possibilities:
1. There's some bug in java thrift library (the java upstream server was
running 0.12.0 the last time we tried it. this time they already upgraded to
0.13.0 but we saw the same problem)
2. Our java server was doing something wrong
3. There's something wrong with TFramedTransport (because there's no
THeaderTransport support in java thrift yet, we have to use TFramedTransport to
talk to the java server).
I'll dig into the java code to figure out which one is it.
> 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)
