http: Put exception in the queue in connection_lost

[mschmitzer]

The client fiber may already be blocked on the queue (in getresponse)
when connection_lost is invoked.

The code in getresponse already handles getting an exception from the
queue.

[coveralls]

Coverage decreased (-0.05%) to 90.193% when pulling 7ce4782 on solute:http-fix-connection-reuse-stall into 1d77ca4 on geertj:master.

[geertj]

Thanks @MarcSchmitzer for the report!

I made the logic slightly more robust to also cover the situation where the connection is lost while reading a response body. Can you have a look at this branch: pr-25, and tell me if it solves your problem?

[mschmitzer]

Hi,
I'm afraid pr-25 doesn't quite cut it for me, it brings back the hung fibers I originally set out to fix. I think the problem is that the _message property of the HttpProtocol instance is never cleared. When connection_lost is invoked on an instance that has already completed one request/response pair, self._message is never None, and so the self._queue.put is not executed.

Maybe clear self._message in on_message_complete?

EDIT: Adding a self._message = None in on_message_complete on top of the pr-25 branch seems to work.

[mschmitzer]

Any updates on this?

I've updated the branch with your variant of the "Put exception in queue" commit and another commit that drops the message object in message_complete to make the former effective.

Would be nice if you could merge and release this.

[coveralls]

Coverage increased (+0.009%) to 90.247% when pulling b48e14b on solute:http-fix-connection-reuse-stall into 1d77ca4 on geertj:master.

[coveralls]

Coverage increased (+0.009%) to 90.247% when pulling b48e14b on solute:http-fix-connection-reuse-stall into 1d77ca4 on geertj:master.

[coveralls]

Coverage increased (+0.009%) to 90.247% when pulling b48e14b on solute:http-fix-connection-reuse-stall into 1d77ca4 on geertj:master.