[
https://issues.apache.org/jira/browse/THRIFT-5240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuxuan Wang resolved THRIFT-5240.
---------------------------------
Fix Version/s: 0.14.0
Resolution: Fixed
> 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
> Priority: Major
> Fix For: 0.14.0
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> 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)
