thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yuxuan Wang (Jira)" <>
Subject [jira] [Created] (THRIFT-5240) Go: do connectivity check on TSimpleServer
Date Thu, 25 Jun 2020 16:48:00 GMT
Yuxuan Wang created THRIFT-5240:

             Summary: Go: do connectivity check on TSimpleServer
                 Key: THRIFT-5240
             Project: Thrift
          Issue Type: Improvement
          Components: Go - Compiler, Go - Library
    Affects Versions: 0.13.0
            Reporter: Yuxuan Wang
            Assignee: Yuxuan Wang

In go's stdlib http package, the http server will cancel the context passed into the request
handler when the client closed the connection ([link|]):

{quote}For incoming server requests, the context is canceled when the client's connection
closes, the request is canceled (with HTTP/2), or when the ServeHTTP method returns.{quote}

This is useful for the handler implementation to be able to abandon the current request to
free up resources that's no longer needed.

Now with socket connectivity check added (THRIFT-5214), it's doable in thrift go library as

Looking at the current code, it needs to be done in compiler generated TProcessorFunction
implementations for each endpoints. What that function does now is basically:

# read the request
# call the handler with the read request
# write the response handler returned

so in order to do that, we can just do the following between step 1 and 2:

# create a sub-context with cancel
# start a goroutine between step 1 and 2, with a ticker (the interval should be a fixed, small
value, maybe 1ms?), do connectivity check on every tick, cancel the context if the connectivity
check failed
# pass that sub-context to the handler, and also cancel the goroutine after the handler returns

one thing to note is that it's not safe to read from the same TTransport concurrently, but
since we don't do any reading after step 1, the goroutine doing connectivity check would be
the only one reading, so a lock is not needed.

the only downside of this approach is that it will create an extra goroutine for each request
in processing. but because of goroutines' are lightweight in nature, this should be fine.

This message was sent by Atlassian Jira

View raw message