Skip to content
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.

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

[question] SUPERSET_WEBSERVER_TIMEOUT deprecated but what is the alternative? #6836

Closed
3 tasks done
anshbansal opened this issue Feb 7, 2019 · 1 comment · Fixed by #6840
Closed
3 tasks done

[question] SUPERSET_WEBSERVER_TIMEOUT deprecated but what is the alternative? #6836

anshbansal opened this issue Feb 7, 2019 · 1 comment · Fixed by #6840

Comments

@anshbansal
Copy link

anshbansal commented Feb 7, 2019

Make sure these boxes are checked before submitting your issue - thank you!

  • I have checked the superset logs for python stacktraces and included it here as text if there are any.
  • I have reproduced the issue with at least the latest released version of superset.
  • I have checked the issue tracker for the same issue and I haven't found one similar.

Superset version

Superset 0.28.1

Expected results

Answer of the question

Actual results

Missing answer

Steps to reproduce

@mistercrunch
Copy link
Member

Looks like this is confusing indeed, the comment comes from #4451 where the auto generated gunicorn command (started through superset runserver) started getting deprecation messages but appears to still work.

The config element SUPERSET_WEBSERVER_TIMEOUT is still used widely across the codebase.

Timeouts are much more complicated than a sane person would expect. Let me document some things here:

  • first your proxy / load balancer / envoy / kong thing may time out before your web server does. When that happen I think nothing is returned and the request is just forever lost. The webserver may still do work, and has no way to return a response.
  • flask offers no way to set a timeout, but your wsgi server does (gunicorn / nginx / ...) when that happens, it does return a proper response with an error code. Without us generating the gunicorn command (per [cli] Preparing to deprecate wrapping of external commands #4451), people have to keep the timeouts in sync manually
  • we have code on the client side that gives up if it looks like it'll never get a timeout response, I'm not sure if it's implement consistently across all "requests that may time out"

Regardless, I think we should remove the " # deprecated" comment and add some notes in there. PR coming up.

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 a pull request may close this issue.

2 participants