Can I set the default response when timeout is occurred?

[sang-jun]

Hi I'm developing a micro service using gunicorn and flask.

My service have to guarantee response time. So, I want to limit the time for processing and If my functions take the time that limited, I want to return default response.

So, I have used timeout_decorator to raise exception when timeout occurred and I have returned default response using @app.errorhandler().

However, this solution has a problem. the timeout decorator works in multiprocessing and my functions work in child process.

So, If my app_context (flask.g) is not guaranteed if it is created in inside of timeout_decorator(child process).

And also, When I use multiprocessing in my functions, sometimes I am in trouble Because ppid at the time of first load and ppid when processing request are different.

Why is this the problem, child process in my functions are implemented to re-spawn when an exception occurs at run-time. But, If the process is re-spawned at run-time, It disappears because the parent is temporary created by timeout decorator.

<I want to do>
gunicorn-master
  |__ gunicorn-worker
              |__ (my functions' child processor)

<Actual>
gunicorn-master
  |__ gunicorn-worker(timeout_decorator)
           |__child of timeout (It runs my functions)
                   |__ (my functions' child processor) (re-spawned)

The first issue can be solved somehow. but second is difficult for me.

So, Is there way to set default response in gunicorn for time-out without timeout_decorator?
Or Is there way to solve processor re-spawn problem?

Thanks!

[benoitc]

why not executing your task in a timed thread instead? The timeout should be less than the gunicorn timeout.

Other way is to just rely on the gunicorn timeout and handle the timeout on the client side instead.

[tilgovi]

You cannot set the response for a timeout because the timeout is first a worker timeout. The timeout is enforced by the master process to kill a worker that may be stuck, such as in an infinite loop, or deadlocked somehow. The master process cannot generate a response, only the worker can. The worker may not be responsive at all.

[tilgovi]

It happens to be the case that for the sync worker the timeout behaves like a request timeout, but this is a confusion that I would like to resolve. See #1493.

[sang-jun]

Thanks @benoitc @tilgovi for your answering.

Since I used the flask app server for development, It processed the request outside of the main thread. But, If the gunicorn worker runs as a one thread, there is no reason to use timeout_decorator as a process! Thanks :)