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
upstream prematurely closed #92
Comments
That's a sort of generic Nginx error that sadly doesn't say much, only that there was a problem in the connection between Nginx and uWSGI, all inside the container. First, check the Docker logs ( Is your endpoint doing a computationally expensive or inherently long computation? You can try adding the Please let me know anything else you discover. |
I have to wait for it to occur because it does not depend on any variable
I'll try it
Absolutely not. |
That's quite strange 🤔 . Is your endpoint receiving a big request? Like a file upload? Or is it returning a long response? Like a big JSON or a big file? Here are the docs for Nevertheless, you could try adding the config and see how it changes. Is just that it would be nice to pinpoint better the actual problem. |
No, it's a simple bootstrap-based flask dashboard with peewee. |
Strange. Then maybe try that and let me know how it goes. |
Tonight it happened again and I checked the docker logs. It seems like the exception "upstream prematurely closed connection while reading response header from upstream" occur as a result of another exception. So nothing to do with this. Even if I do not understand why this exception is triggered sporadically. Following the log: `10.0.201.237 - - [15/Oct/2018:07:06:47 +0000] "GET / HTTP/1.1" 200 4014 "-" "ELB-HealthChecker/2.0" "-" Traceback (most recent call last): During handling of the above exception, another exception occurred: Traceback (most recent call last): During handling of the above exception, another exception occurred: Traceback (most recent call last): 2018/10/15 07:07:49 [error] 11#11: *34318 upstream prematurely closed connection while reading response header from upstream, client: 10.0.200.253, server: , request: "GET / HTTP/1.1", upstream: "uwsgi://unix:///tmp/uwsgi.sock:", host: "myapp.mysite.com" 10.0.200.253 - - [15/Oct/2018:07:07:51 +0000] "GET / HTTP/1.1" 200 4014 "-" "ELB-HealthChecker/2.0" "-" I will try to solve, thanks for the helpI will try to solve, thanks for the help |
I understood where the problem was. My session had a 30-day lifetime but mysql timeout was 8 hours. Saving the database connection within the session made sure that a previously expired connection remained in session and then the exception was triggered. Thank you |
Ah! I see. I'm glad you solved it! Now, as a suggestion: It might be better to create a new connection per request than keeping a single connection forever (I was having problems with that some time ago). The other option that you can try later, would be to have a way to re-use old connections while they are still available but create new ones if they are not. It might get complex easily, so the first approach could be to create a new connection per request. You can have a function that creates it and returns the session to you, and then you can call that function inside each Flask route (function), and use that returned session in the Flask route. If you are using SQLAlchemy, you can combine it with Flask-SQLAlchemy to handle the sessions for you. You can check how to do that with this project generator I created. You can create a project from scratch just to copy the code you need (it's quite simple to generate). The generated project assumes PostgreSQL, but as it uses SQLAlchemy you can just switch the connection line to use MySQL. And just copy the DB related code. |
ok, I'll try it for sure! Thanks again |
It means closing session? |
Hi all,
I recently released an app on AWS ECS using "uwsgi-nginx-flask: python3.7"
The problem is that sporadically, without any reason, the server starts responding with "upstream prematurely closed connection while reading response".
Reading some information on the internet the cause could be due to the use of keepalive on nginx, instead of uwsgi side:
https://stackoverflow.com/a/46092301
or to use proxy_buffering:
owncloud/client#5706 (comment)
Has anyone encountered the same problem?
Thank you all
The text was updated successfully, but these errors were encountered: