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
