Re: libCurl 7.61.1: no response message received indicating dead connection
On Thu, 25 Oct 2018, Daniel Stenberg via curl-library wrote: I would probably recommend calling curl_multi_info_read() unconditionally after each curl_multi_socket_action() call. I could perhaps add that curl_multi_info_read() is explicitly designed to be very fast when there's nothing to return so calling it often should not be a reason for concern. -- / daniel.haxx.se --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: libCurl 7.61.1: no response message received indicating dead connection
On Thu, 25 Oct 2018, Bernd Mueller (bermuell) via curl-library wrote: Regarding how the deletion of timers could cause the issue. We’re using CURLMOPT_TIMERFUNCTION to get informed when to perform a curl_multi_info_read. Is it possible that this is the reason why we don’t get informed about the failing attempt to send the message? Oh. Yes that sounds like the wrong way of doing things. That callback is called to change the expiry timer for the single timeout it needs. When a transfer ends, it doesn't necessarily mean or imply that the timeout situation changes. If so, what other possibilities do you see how to get notified? I would probably recommend calling curl_multi_info_read() unconditionally after each curl_multi_socket_action() call. Or possibly only if the 'running_handles' counter decreases from before and after curl_multi_socket_action() returns. -- / daniel.haxx.se--- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: libCurl 7.61.1: no response message received indicating dead connection
> >> On 12 Oct 2018, at 20:02, Ray Satiro via curl-library >> wrote: >> >> To be clear are you saying that libcurl will no longer indicate when it >> can't connect to the server? The only commit I can find that is related >> to what you are talking about is >> https://github.com/curl/curl/commit/acefdd0 but I don't see how it could >> cause this issue. My understanding is libcurl should call >> Curl_expire_clear. Are you able to reproduce consistently and can you >> confirm that commit is the issue by testing it and its parent? Regarding how the deletion of timers could cause the issue. We’re using CURLMOPT_TIMERFUNCTION to get informed when to perform a curl_multi_info_read. Is it possible that this is the reason why we don’t get informed about the failing attempt to send the message? If so, what other possibilities do you see how to get notified? thanks, Bernd --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: libCurl 7.61.1: no response message received indicating dead connection
> On 12 Oct 2018, at 20:02, Ray Satiro via curl-library > wrote: > > On 10/9/2018 9:40 AM, Bernd Mueller (bermuell) via curl-library wrote: >> I’m reaching out to you as we saw a functional change in libCurl which might >> not have been intended or to get advice how to cope with it on application >> side. >> >> When moving from libCurl version 7.61.0 to 7.61.1 a response message is not >> received anymore >> in case of ‘dead connection’ (‘stream_error’ in multi.c). Where as we >> received in 7.61.0 a response message with error code 7="Couldn't connect to >> server”. >> >> It looks like that the reason is the introduction of the state function >> ‘Curl_init_completed’ for state CURLM_STATE_COMPLETED which stops all the >> timers by calling ‘Curl_expire_clear’. >> >> In the above mentioned error case >> * “Completed” state is the next state >> * as a result, all timers are stopped (which was not the case in v7.61.0) >> * response message which is created afterwards >> (https://github.com/curl/curl/blob/432eb5f5c254ee8383b2522ce597c9219877923e/lib/multi.c#L2133, >> >> with error code indicating the ’timed out’) is never received by the >> application because of the stopped timers...I assume. >> >> I tried not stopping/clearing the timers in that ‘error’ situation and then >> we receive on application side the response message with the expected error >> code in ‘msg->extmsg.data.result’. >> >> Is there a change required on application side to get informed about the >> failing attempt to send the message in that situation? >> >> We’re using >> - libCurl (7.61.1). >> - multi interface to connect to a server using HTTPS. > > To be clear are you saying that libcurl will no longer indicate when it > can't connect to the server? The only commit I can find that is related > to what you are talking about is > https://github.com/curl/curl/commit/acefdd0 but I don't see how it could > cause this issue. My understanding is libcurl should call > Curl_expire_clear. Are you able to reproduce consistently and can you > confirm that commit is the issue by testing it and its parent? yes, that’s what I’m saying. At least the way how a ‘dead connection’ was indicated before the change mentioned above. We have a test case covering this situation and the parent commit (https://github.com/curl/curl/commit/151d3c56d) passes the test, whereas the commit in question (https://github.com/curl/curl/commit/acefdd0) fails. So yes it’s deterministic. When I change the libCurl code of that commit in such a way that the “Curl_expire_clear” is not called _only_ in the ‘dead connection’ situation, we receive the message as expected and all our positive tests and negative tests pass. So the Curl_expire_clear causes a change in behaviour in that specific ‘error situation’. Why, I can’t tell. I had a quick look at the libCurl test cases but couldn’t find one which is covering this situation. --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: libCurl 7.61.1: no response message received indicating dead connection
On 10/9/2018 9:40 AM, Bernd Mueller (bermuell) via curl-library wrote: > I’m reaching out to you as we saw a functional change in libCurl which might > not have been intended or to get advice how to cope with it on application > side. > > When moving from libCurl version 7.61.0 to 7.61.1 a response message is not > received anymore > in case of ‘dead connection’ (‘stream_error’ in multi.c). Where as we > received in 7.61.0 a response message with error code 7="Couldn't connect to > server”. > > It looks like that the reason is the introduction of the state function > ‘Curl_init_completed’ for state CURLM_STATE_COMPLETED which stops all the > timers by calling ‘Curl_expire_clear’. > > In the above mentioned error case > * “Completed” state is the next state > * as a result, all timers are stopped (which was not the case in v7.61.0) > * response message which is created afterwards > (https://github.com/curl/curl/blob/432eb5f5c254ee8383b2522ce597c9219877923e/lib/multi.c#L2133, > > with error code indicating the ’timed out’) is never received by the > application because of the stopped timers...I assume. > > I tried not stopping/clearing the timers in that ‘error’ situation and then > we receive on application side the response message with the expected error > code in ‘msg->extmsg.data.result’. > > Is there a change required on application side to get informed about the > failing attempt to send the message in that situation? > > We’re using > - libCurl (7.61.1). > - multi interface to connect to a server using HTTPS. To be clear are you saying that libcurl will no longer indicate when it can't connect to the server? The only commit I can find that is related to what you are talking about is https://github.com/curl/curl/commit/acefdd0 but I don't see how it could cause this issue. My understanding is libcurl should call Curl_expire_clear. Are you able to reproduce consistently and can you confirm that commit is the issue by testing it and its parent? --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: libCurl 7.61.1: no response message received indicating dead connection
On Fri, 12 Oct 2018, Francisco Sedano Crippa (fsedanoc) via curl-library wrote: I'm also impacted by this issue - Does anybody have any objection if we submit a PR to fix the timer issue Bernd is mentioning? We absolutely appreciate fixes to bugs! This said, I don't grasp how the stopped/removed timers would prevent the status/error to get to the application. I guess your pending PR will reveal that to me! =) -- / daniel.haxx.se --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
Re: libCurl 7.61.1: no response message received indicating dead connection
Hello folks, I'm also impacted by this issue - Does anybody have any objection if we submit a PR to fix the timer issue Bernd is mentioning? Thanks, . .:|:.:|:. Francisco Sedano | CCIE 14859, Tech Lead Software Engineering | CSG Enterprise Access and Services Group (EASG) On 09.10.18, 16:06, "curl-library on behalf of Bernd Mueller (bermuell) via curl-library" wrote: Hello, I’m reaching out to you as we saw a functional change in libCurl which might not have been intended or to get advice how to cope with it on application side. When moving from libCurl version 7.61.0 to 7.61.1 a response message is not received anymore in case of ‘dead connection’ (‘stream_error’ in multi.c). Where as we received in 7.61.0 a response message with error code 7="Couldn't connect to server”. It looks like that the reason is the introduction of the state function ‘Curl_init_completed’ for state CURLM_STATE_COMPLETED which stops all the timers by calling ‘Curl_expire_clear’. In the above mentioned error case * “Completed” state is the next state * as a result, all timers are stopped (which was not the case in v7.61.0) * response message which is created afterwards (https://github.com/curl/curl/blob/432eb5f5c254ee8383b2522ce597c9219877923e/lib/multi.c#L2133, with error code indicating the ’timed out’) is never received by the application because of the stopped timers...I assume. I tried not stopping/clearing the timers in that ‘error’ situation and then we receive on application side the response message with the expected error code in ‘msg->extmsg.data.result’. Is there a change required on application side to get informed about the failing attempt to send the message in that situation? We’re using - libCurl (7.61.1). - multi interface to connect to a server using HTTPS. thanks a lot for your help, Bernd --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
libCurl 7.61.1: no response message received indicating dead connection
Hello, I’m reaching out to you as we saw a functional change in libCurl which might not have been intended or to get advice how to cope with it on application side. When moving from libCurl version 7.61.0 to 7.61.1 a response message is not received anymore in case of ‘dead connection’ (‘stream_error’ in multi.c). Where as we received in 7.61.0 a response message with error code 7="Couldn't connect to server”. It looks like that the reason is the introduction of the state function ‘Curl_init_completed’ for state CURLM_STATE_COMPLETED which stops all the timers by calling ‘Curl_expire_clear’. In the above mentioned error case * “Completed” state is the next state * as a result, all timers are stopped (which was not the case in v7.61.0) * response message which is created afterwards (https://github.com/curl/curl/blob/432eb5f5c254ee8383b2522ce597c9219877923e/lib/multi.c#L2133, with error code indicating the ’timed out’) is never received by the application because of the stopped timers...I assume. I tried not stopping/clearing the timers in that ‘error’ situation and then we receive on application side the response message with the expected error code in ‘msg->extmsg.data.result’. Is there a change required on application side to get informed about the failing attempt to send the message in that situation? We’re using - libCurl (7.61.1). - multi interface to connect to a server using HTTPS. thanks a lot for your help, Bernd --- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
