You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: (opt-in): terminate handling of work when the request has already timed out (GoogleCloudPlatform#328)
Overhead-free (or at least very cheap).
The “timeout” gunicorn config means drastically different things for
sync and non-sync workers:
> Workers silent for more than this many seconds are killed and restarted.
>
> Value is a positive number or 0. Setting it to 0 has the effect of
> infinite timeouts by disabling timeouts for all workers entirely.
>
> Generally, the default of thirty seconds should suffice. Only set this
> noticeably higher if you’re sure of the repercussions for sync workers.
> For the non sync workers it just means that the worker process is still
> communicating and is not tied to the length of time required to handle a
> single request.
So. For cases where threads = 1 (user set or our defaults), we’ll use
the sync worker and let the regular timeout functionality do its thing.
For cases where threads > 1, we’re using the gthread worker, and timeout
means something completely different and not really user-observable. So
we’ll leave the communication timeout (default gunicorn “timeout”) at 30
seconds, but create our own gthread-derived worker class to use instead,
which terminates request handling (with no mind to gunicorn’s “graceful
shutdown” config), to emulate GCFv1.
The arbiter spawns these workers, so we have to maintain some sort of
global timeout state for us to read in our custom gthread worker.
In the future, we should consider letting the user adjust the graceful
shutdown seconds. But the default of 30 seems like it’s worked fine
historically, so it’s hard to argue for changing it. IIUC, this means
that on gen 2, there’s a small behavior difference for the sync workers
compared to gen 1, in that gen 2 sync worker workloads will get an extra
30 seconds of timeout to gracefully shut down. I don’t think monkeying
with this config and opting-in to sync workers is very common, though,
so let’s not worry about it here; everyone should be on the gthread path
outlined above.
* fix tests
* small test fixes
give up on coverage support for things that are tested in different
processes, or in gthread, because it looks like pytest-cov gave up on
support for these, where as coverage has out-of-the-box support
* format
* isort everything
* skip tests on mac
there's something test-specific about how mac pickles functions for
execution in multiprocessing.Process which is causing problems. it
seems somewhere in the innards of flask and gunicorn and macos...
since this feature is opt-in anyway, let's just skip testing darwin.
* sort tuple of dicts in async tests before asserting
causes flakes sometimes in workflows
* use double-quotes
* also skip tests on windows - this is all built for gunicorn, there's no
value adding it for windows anyway
* skip import on windows
* easy stuff
* add a few tests for sync worker timeouts
these shouldn't have changed with this commit
0 commit comments