commit e3739920c4db97f255ab973cf125f0091bb15428
Author: Samuel Merritt <email address hidden>
Date: Wed Jun 13 14:28:28 2018 -0700
Fix socket leak on object-server death
Consider a client that's downloading a large replicated object of size
N bytes. If the object server process dies (e.g. with a segfault)
partway through the download, the proxy will have read fewer than N
bytes, and then read(sockfd) will start returning 0 bytes. At this
point, the proxy believes the object download is complete, and so the
WSGI server waits for a new request to come in. Meanwhile, the client
is waiting for the rest of their bytes. Until the client times out,
that socket will be held open.
The fix is to look at the Content-Length and Content-Range headers in
the response from the object server, then retry with another object
server in case the original GET is truncated. This way, the client
gets all the bytes they should.
Note that ResumingGetter already had retry logic for when an
object-server is slow to send bytes -- this extends it to also cover
unexpected disconnects.
Reviewed: https:/ /review. opendev. org/690644 /git.openstack. org/cgit/ openstack/ swift/commit/ ?id=e3739920c4d b97f255ab973cf1 25f0091bb15428
Committed: https:/
Submitter: Zuul
Branch: stable/rocky
commit e3739920c4db97f 255ab973cf125f0 091bb15428
Author: Samuel Merritt <email address hidden>
Date: Wed Jun 13 14:28:28 2018 -0700
Fix socket leak on object-server death
Consider a client that's downloading a large replicated object of size
N bytes. If the object server process dies (e.g. with a segfault)
partway through the download, the proxy will have read fewer than N
bytes, and then read(sockfd) will start returning 0 bytes. At this
point, the proxy believes the object download is complete, and so the
WSGI server waits for a new request to come in. Meanwhile, the client
is waiting for the rest of their bytes. Until the client times out,
that socket will be held open.
The fix is to look at the Content-Length and Content-Range headers in
the response from the object server, then retry with another object
server in case the original GET is truncated. This way, the client
gets all the bytes they should.
Note that ResumingGetter already had retry logic for when an
object-server is slow to send bytes -- this extends it to also cover
unexpected disconnects.
Change-Id: Iab1e07706193dd c86832fd2cff0d7 c2cb6d79ad9 17b5a116875b51a 781b33a7abf 3146fce17f61f2a b9e01eb684)
Related-Change: I74d8c13eba2a49
Closes-Bug: 1568650
(cherry picked from commit 0e81ffd1e1481a7