Bug #78485 [Com]: Random "couldn't resolve host" failures in curl_multi
| From: | sinus at sinpi dot net | Date: | Mon, 02 Sep 2019 20:54:23 +0000 |
| Subject: | Bug #78485 [Com]: Random "couldn't resolve host" failures in curl_multi | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-222532@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=78485&edit=1
ID: 78485
Comment by: sinus at sinpi dot net
Reported by: sinus at sinpi dot net
Summary: Random "couldn't resolve host" failures in
curl_multi
Status: Open
Type: Bug
Package: HTTP related
Operating System: CloudLinux
PHP Version: 7.2.22
Block user comment: N
Private report: N
New Comment:
You might have to reload it a few times, as I said, it's pretty random. Reproductions of the
bug are seen as "Msg: 6 for handle <x>".
Previous Comments:
------------------------------------------------------------------------
[2019-09-02 20:51:30] sinus at sinpi dot net
The issue can be seen at http://djab.eu/isuvu/bug.php
with source viewable at http://djab.eu/isuvu/bug.php.txt .
------------------------------------------------------------------------
[2019-09-02 20:35:04] nikic@php.net
Is there any publicly accessible host for which this might be reproduced?
------------------------------------------------------------------------
[2019-09-02 20:33:25] sinus at sinpi dot net
I finally managed to make a workaround, the hard way: by stashing the failed handles and starting a
whole new curl_multi_init session with just the failures. The original problem remains, though: why
would n+1 handles immediately fail to resolve.
------------------------------------------------------------------------
[2019-09-02 19:39:20] sinus at sinpi dot net
Trying another workaround, I built another retry mechanism, storing the failed downloads for later
and only re-queuing them once the "good" downloads complete (getting a result==0 in
curl_multi_info_read). However, it would seem that curl_multi does not, in fact, like having its
list modified when it's running: my newly created curl_init handles, added anew, simply got
ignored: curl_multi_exec's $still_running return silently dropped by one on the next round, as
if it merely removed the new handle from its list.
So another question arises - CAN curl_multi actually handle additions or removals of its child
handles while in a curl_multi_exec session..?
------------------------------------------------------------------------
[2019-09-02 17:55:02] sinus at sinpi dot net
To try and work around the issue, I wrote a retry mechanism - if a CURLE_COULDNT_RESOLVE_HOST
message is detected, I curl_multi_remove_handle the handle, curl_close it, make a new curl_init and
curl_multi_add_handle again, and return to calling curl_multi_exec. The docs don't state
whether adding or removing handles during a multi session is permitted, so why not give it a try.
The result, however, was exactly the same. All of the newly re-added child handles immediately got
CURLE_COULDNT_RESOLVE_HOST results.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=78485
--
Edit this bug report at https://bugs.php.net/bug.php?id=78485&edit=1