[jira] [Created] (THRIFT-5240) Go: do connectivity check on TSimpleServer

["Yuxuan Wang (Jira)" <ji...@apache.org>]

Yuxuan Wang created THRIFT-5240:
-----------------------------------

             Summary: Go: do connectivity check on TSimpleServer
                 Key: THRIFT-5240
                 URL: https://issues.apache.org/jira/browse/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|https://pkg.go.dev/net/http?tab=doc#Request.Context]):

{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 well.

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
(v8.3.4#803005)