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.
* 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.
* Magical failures.
More c-ares bugs?
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.
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.
Has anyone else given both schemes a real-world test in a million-seat application?
Not me anyway. -- / daniel.haxx.se ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
