8000 Expose a future for currently running requests · Issue #3009 · tornadoweb/tornado · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Expose a future for currently running requests #3009

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
delfick opened this issue Apr 4, 2021 · 2 comments
Closed

Expose a future for currently running requests #3009

delfick opened this issue Apr 4, 2021 · 2 comments

Comments

@delfick
Copy link
delfick commented Apr 4, 2021

Hello,

Is it possible to have a future for each request that has received headers but is yet to be finished?

I want to be able to wait on these when I stop the server rather than waiting an arbitrary amount of time hoping that all current requests finish in that time.
@bdarnell
Copy link
Member

This is something you could build at the application layer - either in an override of prepare() and on_finish or wrapping your Application and implementing the HTTP delegate interfaces. But I think just exposing Futures would be awkward to use and may not solve the problem - it doesn't on its own prevent new requests from coming in. For something built-in I think it would be better to add an explicit graceful drain mode that would stop the server from accepting new connections.

However, I'm a strong advocate of time-based shutdown mechanisms instead of trying to track open requests. I give my logic in #1791 (comment). I'm going to mark this as a duplicate of #1791 since that's the main issue we have tracking graceful shutdown discussions.

@delfick
Copy link
Author
delfick commented Apr 10, 2021 •
edited
Loading
5D59

I agree with waiting a timeout, my problem is I want to quit earlier if there's no requests left and it felt hacky to have to subclass my handlers and add this kind of code and use the subclass instead.

I'll stick with timeouts then. thanks :)

Also, I was under the impression that http_server.stop() already stops accepting new connections (and the way we deploy in kubernetes means it won't get new requests at that point anyway)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@delfick @bdarnell
0