With gunicorn 19.6.0 release and with max_requests=50 I can see the client receives TCP RST before actually receiving the complete response to the last request. The last response gets http fragmented to 3 packets and the tcp rst is received after packet 1 so client respectively closes the connection without further due. I could confirm this also with wireshark:
7656 18:38:46.826934643 172.18.0.11 172.18.0.12 HTTP 224 HTTP/1.1 200 OK
7659 18:38:46.837182351 172.18.0.11 172.18.0.12 TCP 66 5000→56598 [RST, ACK] Seq=1983 Ack=1086 Win=33280 Len=0 TSval=5961918 TSecr=5961914
7660 18:38:46.837373308 172.18.0.11 172.18.0.12 HTTP 341 Continuation
7661 18:38:46.837431978 172.18.0.11 172.18.0.12 HTTP 67 Continuation
Confirmed that disabling the feature by setting max_requests and max_requests_jitter to 0 fixes the issue.
After 50, the worker is killed. If the max is set, so if a request arrives to in between, the system might be returning an answer to the client.
receiving the complete response to the last request. what do you mean by last ?
receiving the complete response to the last request.
by last request I meant the 50th request after which the worker was killed. The worker was killed before the client received the complete response (the response is http fragmented to 3 separate messages) to the 50th request.
most probably your client is sending immediately the request. Gunicorn close the request once accepted which can trigger such cases imo. If you have the control on your client you may want to try with TCP_NODELAY set to false. Let me know about the result..
If you can provide a way to reproduce this that shows a problem, such as a connection being terminate before the whole body is sent, please let us know. The worker type will help, too. The worker should not terminate until the whole request has been at least sent to the kernel's TCP stack.