Comment 4 for bug 667956

Well... not exactly. I mean... if the "problem" is the printed traceback - then yes it fixed.

You can still see the ValueError raised and "handled" by the client disconnect generic exception logging. Then it still gets raised again outside of swift, in the eventlet.wsgi server's finally block in the last stanza of handle_one_response - if you have eventlet_debug=True, you can still see it hit stdout, but since it's in a spawn_n you can't catch it.

So... we *really* should address this ugly bug upstream. There's a nice IOError that get's raised if eventlet.wsgi encounters an unexpected EOF during chunked transfer, but no errors raised from read seem to be dealt with in the finally block.

Then there's the swift problem which seems to not close down connections to the backend servers during the generic handling of client disconnect (at least not in the PUT object case).

e.g.

run this:

http://paste.openstack.org/show/27931/

then run:

    sudo netstat -pant

.. you'll see a bunch of established connections to and from object servers (60X0).

then run:

    swift-init proxy stop

... you'll see all of the object servers abruptly abort their connections.

I guess there's a max_upload_time setting on the object server to close down some of this, but I never let it get that far. I don't see a chunk read timeout on the object server...

This is my current approach:

http://paste.openstack.org/show/27931/

But a Timeout on the read's in the object server might make more sense if we could get the timing right :\

Anyways, that is to say, if you want to close this one - I'll have to open another issue(s) :P