Presently, the wsgi server allows persist connections hence even after
the response is sent to the client, it doesn't close the client socket
connection.
Because of this problem, the green thread is not released back to the pool.
In order to close the client socket connection explicitly after the
response is sent and read successfully by the client, you simply have to
set keepalive to False when you create a wsgi server.
Add a parameter to take advantage of the new(ish) eventlet socket timeout
behaviour. Allows closing idle client connections after a period of
time, eg:
$ time nc localhost 8776
real 1m0.063s
Setting 'client_socket_timeout = 0' means do not timeout.
Reviewed: https:/ /review. openstack. org/177670 /git.openstack. org/cgit/ openstack/ keystone/ commit/ ?id=67cda0ccae0 4471340bcada099 d945d90979e64d
Committed: https:/
Submitter: Jenkins
Branch: stable/kilo
commit 67cda0ccae04471 340bcada099d945 d90979e64d
Author: abhishekkekane <email address hidden>
Date: Tue Oct 21 04:10:57 2014 -0700
Eventlet green threads not released back to pool
Presently, the wsgi server allows persist connections hence even after
the response is sent to the client, it doesn't close the client socket
connection.
Because of this problem, the green thread is not released back to the pool.
In order to close the client socket connection explicitly after the
response is sent and read successfully by the client, you simply have to
set keepalive to False when you create a wsgi server.
Add a parameter to take advantage of the new(ish) eventlet socket timeout
behaviour. Allows closing idle client connections after a period of
time, eg:
$ time nc localhost 8776
real 1m0.063s
Setting 'client_ socket_ timeout = 0' means do not timeout.
DocImpact: socket_ timeout option (default=900).
Added wsgi_keep_alive option (default=True).
Added client_
SecurityImpact
Closes-Bug: #1361360 bca78dfc83199ef 17d9a7ea5b7 aca51a36250ae93 105c17f6c4)
Change-Id: I03b9c5c64f4bd8
(cherry picked from commit 3b08644eb9cf4c5