On Mon, Jan 14, 2013, Daniel Stenberg wrote:
> On Fri, 11 Jan 2013, Yang Tse wrote:
>
>>> 00:25:55.571476 == Info: Recv failure: Connection reset by peer
>>> 00:25:55.571476 == Info: Connection died, retrying a fresh connect
>>>
>>> ... it doesn't look like this is truly trying a fresh connect, it seems
>>> to
>>> mostly just _say_ it!
>>
>>
>> Yep, something could probably be improved.
>
>
> This is meant to get trapped in lib/multi.c:1444 for the CURLM_STATE_PERFORM
> state, but clearly it isn't or it isn't acting correctly. Can you figure out
> if the if() matches and the action is wrong or if it never even invokes
> Curl_retry_request() there?

In this case multi attempts to re-use an existing connection returned
by ConnectionExists() which happens to be alive when checked inside
ConnectionExists().

[Marker A]

When trying to use this connection in multi.c:1430 with
Curl_readwrite() it finds that the connection has already been
disconnected. easy->result gets CURLE_RECV_ERROR in multi.c:1430 and
'done' is FALSE.

Condition tested in multi.c:1444 is true and as such
Curl_retry_request() is called.

Curl_retry_request() call in multi.c:1449 returns 0 into 'ret'
variable and sets (newurl != NULL)

With above results, multi.c:1455 gets executed setting easy->result =
CURLE_OK. Making next line of code actually executed multi.c:1536.
Remaining in CURLM_STATE_PERFORM state.

Next call to multi_runsingle() makes it iterate again in
CURLM_STATE_PERFORM state, and as such, same as flow control and
results as described from [Marker A] above down to here are repeated
endlessly.

So the issue there is that the retrying logic there has to be somehow
controlled or used differently.

Adding in multi.c:1444 an additional condition such as && ( !
easy->easy_conn->bits.reuse) avoids the endless loop, but it subverts
the purpose of the 'retrying' (at least as described in lines 1445 to
1447).

Checking there if the socket is dead can also be done, but happens the
same as above.

Introducing some sort of retry control, count-based, time-based, or
both as we do in tool_operate.c lines 1362 to 1382 would limit the
number of iterations.

And finally the big question. Do we really have to retry
CURLM_STATE_PERFORM upon such conditions or should this be going to a
previous state or aborting upon a given retry count or even at first
failure?

-- 
-=[Yang]=-
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html