cURL / Mailing Lists / curl-library / Single Mail


Issues in constraining number of open connections with curl multi interface

From: Mukul Kedare <>
Date: Wed, 28 Dec 2011 18:51:55 +0530


In our multi threaded application we are maintaining a pool of connections
(pool of easy handles for each URL).

The connection pool has limited set of easy handles per URL.

All the threads, have their own multi handle to which we add the easy
handles from the connection pool based on the URLs to which the requests
are to be made.

For example,

We have 5 URLS, corresponding to them we have 5,10,20,8,30 easy handles in
the connection pool respectively.
Connections opened for a perticular URL should not be more than their
respective pool size.
Say for* URL_1* pool size is 5, in that case there should not be more than
5 curl easy handles in use at a time.
This pool is used in multi-threaded application , so if there are 100
threads running , at a time only 5 threads should be able to open
connections to *URL_1*

Note that, we want to maintain persistent connections , hence we are *not
doing cleanup of easy and multi handles*.

The Problem we are facing is that there are open connections more than the
pool size of a perticular URL.

So, for *URL_1* we expect 5 open connections at a time but we see open
connections more than that.

We observed that curl does the connection caching internally(*checked it
with the netstat command, showing established connections for URL_1 more
than 5*).

To solve this, we tried using *CURLMOPT_MAXCONNECTS* and *
CURLOPT_MAXCONNECTS* but it is not working.

We then tried out *CURLOPT_FORBID_REUSE* (closing the connection explicitly
after use), this worked for limiting the open established connections
(however we observed more connections in TIME WAIT states).

With *CURLOPT_FORBID_REUSE* we solved the problem of constraining the
number of open connections , but we also want to keep persistent
connections which is not achived by this option.

Please suggest how do we *limit the number of open connections without
giving away persistence of connection*.


List admin:
Received on 2011-12-28