On Tue, 17 Sep 2013, Daniel Stenberg wrote:
On Mon, 16 Sep 2013, m brandenberg wrote:
* General unreliability on platforms with DNS timeouts on all
three platforms.
This sounds like a bug, in either c-ares or libcurl.
Possibly. But it could also be multiple causes. The
problem in these scenarios is that it is the result of the
local environment. I have very little success reproducing
these in the development environment.
* OS X is having trouble keeping /etc/resolv.conf valid. Either
the symlink is damaged or the target (/var/run/resolv.conf)
isn't being regenerated reliably on network reconfigurations.
Result is a broken server list in c-ares.
This sounds like a broken OS X or that c-ares needs to get its list of
servers differently.
Both, I think. But using the native system to extract server
information while supporting multiple OS versions leaves you
chasing changes. Like the transition away from NetInfo in
the case of OSX.
* Magical failures.
More c-ares bugs?
No, environment, I think, and c-ares is the victim. As the
main OSs have acquired deeper networking functions and things
like anti-viruses and firewalls keep adding new features to
attract users, surprising behaviors are coming out of the
systems.
But looking at the implementation of the threaded resolver makes me ask a
few questions. It's a thread-per-request scheme. Good for avoiding a
stall behind a request that will timeout or be answered slowly. But this
makes unbounded demands on thread count.
Yes. Of course that could be modified/improved but it would also make things
more complicated and you'd also get problems with one slow resolve hogging
the other subsequent resolves if you just use a queue in a single resolver
thread.
Yep, I am thinking of an optional something in between "one or all".
Parameter on a multi limiting the number of outstanding requests
or an EAGAIN-like status between libcurl and the c-ares/TR api.
*If* it is a problem in practice. I wonder if anyone has seen
a problem with the threaded resolver in the field.
The c-ares we're using *is* old, 1.7.1, and that will get bumped up but
maybe it's time to change.
Some of your problems may have been fixed since that version. Development may
be slow in c-ares but there are like 8 releases done since that version.
Yeah, I will likely roll forward anyway. The test cycle is
sadly slow and unreliable for this set of problems...
m
--
Monty Brandenberg
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
