Re: Random "couldn't resolve host" failures in curl_multi

On 2019-09-01 23:33, Daniel Stenberg wrote:
On Sun, 1 Sep 2019, Sinus via curl-library wrote:

Also, it's always the final handles that fail - n first handles work,
n+1 till the end fail to resolve, with n sometimes being all 12,
sometimes 8, a few times 4, but I also caught it on 11.

"couldn't resolve host" means that the name resolving failed. I can't
think of a sensible reason why that would fail for just a few parallel
requests. You probably want to check what's happening under the hood
to figure out why. Like perhaps wireshark the connection and watch the
DNS replies.

It seems overly aggressive for a rate-limiter to kick in, but who knows.

How would you suggest that I check that vector? Write a C program that
would send DNS requests in rapid succession, trying to trip the rate
limiter?
I'm not so sure my hosting would like that... :>

- what could be causing this to happen randomly?

I doubt it is random, it's more likely that you haven't figured out
the pattern...

All I know is that each time I reload the PHP page that fetches 12 URLs,
I get
different results: sometimes all 12 load, but most often 8 load, with
other
numbers seldom making an appearance. Obviously there is a pattern behind
every
"random", but so far I haven't found it. I'm afraid I might have to just
write
some fallbacks to grab the missed URLs, before I have time to figure out
the
pattern.

- why isn't the error stored in the child handle?

I don't know, I don't think that's how libcurl itself works but smells
like possibly introduced by the PHP layer (which is maintained and
authored by the PHP team).

That's what I feared... I'm off to bug them, then - especially having
confirmed through #curl on FreeNode that curl_multi isn't exactly in
libcurl
core.

Cheers,

--
Sinus
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html