> Under the high-load simulation, after some minutes, curl_easy_perform
> responses always with a CURLE_COULDNT_CONNECT (7).
> But the host is still connectable. Sometimes the CURLE_COULDNT_CONNECT
> comes for only one try, sometimes it's endless returning
> CURLE_COULDNT_CONNECT.
>
>
It is not easy to tell without traces taken by setting CURLOPT_VERBOSE
option. If your SW is really running fast and leaking sockets, you may be
running out of file descriptors needed for socket creation. The error code
returning from socket would tell. To easily test, - if your app is launched
from a console - just try to decrease it to a lower value like 64 and
expect a shorter time span before failure. Below is the command to decrease
# of allowed open files

ulimit -a | grep "open files" # check current limit
# ulimit -n 64 # set a new limit
ulimit -a | grep "open files" # check updated limit

>
> If i relaunch the application libcurl manages to connect fine as it was
> before.
> i did also check for mem leak: all fine.
>
>
Relaunching the applicaiton will tell Linux kernel to cleanup (close/free)
sockets - file descriptors for you. That may support my theory.

> If somebody also works with FTP:
> How do you handle CURLE_COULDNT_CONNECT?
> Do you try to make server tries?
>
>
You should normally not handle. A proper engineering should protect from
traping to this error.

---
it is twice as difficult to debug a program as to write it. Therefore, if
you put all of your creativity and effort into writing the program, you are
not smart enough to debug it.

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-11-04