Give taken-over connections a shutdown grace
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 34/100
Research direction
Start in gonsole/serve.go: serveOn accepts connections and drain waits during shutdown, and countedListener in gonsole/idle.go shows how connections are already counted until close. Read how ServeListening and Serve return on cancel in gonsole/program.go. Done means a test with a handler that takes a connection over and keeps it open makes drain wait up to Grace and CancelGrace, then close it, instead of returning at once.
Written by the indexing model from the issue text.
Description
Downstream applications that hold WebSockets need them to end cleanly when the server stops.
Current state: a handler can take a connection over from net/http, as a WebSocket does (Go calls this hijacking). Shutdown "does not attempt to close nor wait for hijacked connections" (net/http/server.go:3264-3268). With an idle exit, gonsole counts such a connection until it closes, but drain, the wait at shutdown (gonsole/serve.go:141-169), does not wait for it. A test on gonsole 0.8.0 took a connection over and let its handler return. On a cancel, as on SIGTERM (gonsole/program.go:97), ServeListening and Serve returned nil within a millisecond, though Grace was 2 seconds. The connection still echoed after the return. Shutdown starts the srv.RegisterOnShutdown functions without waiting (net/http/server.go:3281). A goodbye that took 300 ms came after the return, and a real process may have exited by then.
Proposal: in serveOn (gonsole/serve.go:92-116), which both call, keep every accepted connection in a set until its first close, as countedListener counts them (gonsole/idle.go:107-115). drain then waits for the set to empty within Grace and CancelGrace, then closes what is still open, as Traefik does. Test it with a handler that keeps a taken-over connection open.
Trigger: a downstream application needs WebSockets to close cleanly on a restart.
- Dominant language
- Go
- Stars
- 69
- Forks
- 3
- Avg merge
- 9h 11m
- Merged PRs (30d)
- 38
Getting set up
This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from gopherium/framework
-
bug help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
enhancement help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
Maintainers usually reply within 1 day
-
enhancement help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 1 day
-
enhancement help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Stop a SQLite commit that waits for a lock once its transaction's context endsPossibly taken @SirLouen claimed this 1 day ago. Openbug
Difficulty 4/5 3-5 days Newbie friendliness 48/100
gopherium/framework#104 · 1 comment · 1 assignee ·
Maintainers usually reply within 1 day
All issues in gopherium/framework
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 67/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 64/100
FiloSottile/age#758 ·
-
nginx configOpen
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
Maintainers usually reply within 2 days
-
fix: the buttons mock cannot take back the match point -- its undo looks only for the running matchOpenbug
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
stuttgart-things/zaehlwerk#168 ·
Maintainers usually reply within 1 day