cURL / Mailing Lists / curl-library / Single Mail


Re: [PATCH 2/7] pipelining: Fix connection handling under timeouts.

From: Carlo Wood <>
Date: Sun, 16 Nov 2014 22:46:07 +0100

On Sun, 16 Nov 2014 21:58:13 +0100
Carlo Wood <> wrote:

> + /* We can't use the connection if the connection can't be
> reused,
> + or is marked for closure due to an error (ie a timeout).
> */
> + if(check->bits.close)
> + continue;

I suppose this isn't really needed anymore now that Curl_disconnect()
was called... I continued testing without that.

Now back to my (and Monty's) concern with the changes you made
to my patch (2/7). One thing that is still broken with this attempt
is the connect/close flood that I mentioned in my commit message.

With the last patch, my testsuite generates the following output:

* Operation timed out after 1001 milliseconds with 0 bytes received
* Marked for [closure]: Disconnected with pending data
* Closing connection 0

Ok, that is the call to Curl_disconnect() that we made it do
in the patch.

* The cache now contains 0 members
* Pipe broke: handle 0xdcb028, url = /

One of the other requests in the pipe notice that the pipe broke
and want to reconnect:

* STATE: WAITPERFORM => CONNECT handle 0xdcb028; line 952 (connection
* Added connection 1. The cache now contains 1 members
* Hostname was found in DNS cache
* Trying
* STATE: CONNECT => WAITCONNECT handle 0xdcb028; line 1083 (connection
* Connected to localhost ( port 9000 (#1)
* Marked for [keep alive]: HTTP default
* STATE: WAITCONNECT => WAITDO handle 0xdcb028; line 1229 (connection
* WAITDO: Conn 1 send pipe 1 inuse FALSE athead TRUE
* STATE: WAITDO => DO handle 0xdcb028; line 1268 (connection #1)

It connected and went all the way to state DO... and THEN finds
out that it timed out (that has always been the case).
* Operation timed out after 0 milliseconds with 0 out of 0 bytes

And then (!):

* Marked for [closure]: Disconnected with pending data
* Closing connection 1

... closes the FRESH connection that was JUST made BEFORE
actually sending any data over it!

With my patch, which remmembers connection_id of connections
that data is *actually* sent over, this does not happen: the connection
is kept and used for other requests.

The above happens again for every request in the pipe (that also timed
out), hence leading to a burst/flood of connects and disconnects.

Carlo Wood <>
List admin:
Received on 2014-11-16