Skip to content

Conversation

@vtho
Copy link

@vtho vtho commented Mar 1, 2022

couple of comments about ur observation

If context timeout kills a TCP connection, we would expect to see a failure for the 2nd http request from the client to the middleware. But from this demo it was evident that we succesfully sent an HTTP request to the middleware.

why would we expect a failure on the 2nd request? a new conn would be spun up to serve it

If context timeout kills a TCP connection, we would expect that once the 80 msec context times out, the middleware process ends and it drops the request in the middle of its sleep. In reality though, the connection between client and middleware is not affected by the request's context timeout. And that is testified when middleware succesfully wakes up from its short 2 sec nap.

i think there's some confusion here. you're assuming goroutine is the "connection", what actually happens is the middleware server starts up a http server that accepts new http conns. the http server likely itself is a long running goroutine. when receiving requests, it'll spin up additional goroutines to handle the request. ur sleep is in that goroutine. if u want that app logic to be context aware, a sleep will not work (its blocking). you can use a select instead:

// sub ur sleep with this
select {
	case <-time.After(2 * time.Second):
	case <-r.Context().Done():
		log.Println("[MIDDLEWARE] context canceled")
		http.Error(w, r.Context().Err().Error(), 500)
		return
	}

the code i changed uses httptrace to inspect the connection state. im trying to point out the scenario where a conn is reused or created. the 1st and 2nd show that a timeout causing the next conn to be new. whereas the 3rd and 4th show that with no timeout, a conn is reused

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant