Comment 21 for bug 1174660

Reviewed: https://review.openstack.org/48538
Committed: http://github.com/openstack/swift/commit/def37fb56aea7b9fe4254621e10667712052d3ac
Submitter: Jenkins
Branch: master

commit def37fb56aea7b9fe4254621e10667712052d3ac
Author: Samuel Merritt <email address hidden>
Date: Wed Sep 25 10:41:41 2013 -0700

    Stop reading from object server when client disconnects.

    If a client were in the middle of an object GET request and then
    disconnected, the proxy would wait a while (default 60s) and then time
    out the connection. As part of the teardown for this, the proxy would
    attempt to close the connection to the object server, then drain any
    associated buffers. However, this didn't work particularly well,
    resulting in the proxy reading the entire remainder of the object for
    no gain.

    Now, the proxy closes the connection hard, by calling .close() on the
    underlying socket._socket object. This is different from calling
    .close() on a socket._socketobject object, which is what you get back
    from socket.socket() and similar methods. Calling .close() on a
    socket._socketobject simply decrements a reference counter on the
    socket._socket, which has been observed in the past to result in
    socket leaks when something holds onto a reference. However, calling
    .close() on a socket._socket actually closes the socket regardless of
    who else has a reference to it.

    I had to delete a test assertion that said the object server never got
    SIGPIPE after a GET w/X-Newest. Well, you get a SIGPIPE when you write
    to a closed socket, and now the proxy is actually closing the sockets
    early, so now you *do* get a SIGPIPE.

    closes-bug: 1174660

    Note that this will cause a regression on bug 1037337; unfortunately,
    the cure is worse than the disease, so out it goes.

    Change-Id: I9c7a2e7fdb8b4232e53ea96f86b50e8d34c27221