Multi-threading and name resolution issues
Date: Tue, 2 Aug 2011 17:48:48 -0700
I am writing a C++ program that communicates with web-services; I am using
libcurl to talk HTTP with the web services. My program is multi-threaded and
is quite chatty with the web services (interacts periodically every few
seconds). For this reason, I am using a pool of CURL handles to avoid a
massive socket churn. I have read the documentation and other posts
regarding caveats with multiple threads, so I have taken care to make sure
each handle is used by only one thread at a time, although I bounce the
handles between different threads. I have not encountered any problems in
this area. However, I am noticing problems connecting to the web server
after a few hours(I am getting a CURLE_COULDNT_CONNECT error). I am
suspecting this could be due to the name resolution issue. I am using the
libcurl that is baked into Centos 6 and so it is not linked against a-res
lib. For various reasons, we prefer to use the libcurl that comes with our
distro instead of compiling our own. I would like to know if there is any
alternative option that I could code in my program to overcome the a-res
limitation. I have tried, so far, a couple of options to verify if I can
work around the name resolution problem.
The first option I have tried is to retry after resetting the handle when I
receive the connection error by calling curl_easy_duphandle. This did not
work, I continue to get CURLE_COULDNT_CONNECT errors. My understanding of
curl_easy_duphandle is likely not correct.
The second option I have tried is to set up timers on my CURL handle pool
and reset (using curl_easy_duphandle) the handles on the expiry of a
pre-configured timeout (occurs before I get the connection or name
resolution error); I have not tested this yet.
Please let me if these are viable options. I also want to know if there is
simply no way of getting multiple threads and persistent handles to work
consistently without linking against the a-res lib.
List admin: http://cool.haxx.se/list/listinfo/curl-library
Received on 2011-08-03