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)
