On Wed, 28 Dec 2011, Mukul Kedare wrote:

> 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.

Keeping easy handles around for a multi handle will not affect the connection
pool at all. The pool is kept within the multi handle completely separate from
the easy handles to allow applications to not have to bother about such
stunts.

> 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.

Are you talking about easy handles or actual connections? You can of course
make sure you only have 5 handles for a specific URL at any one time, but you
can't as easily know or control the amount of idle connections kept in all the
pools that are still connected.

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

Only if you add more handles than what you set the size to be I think. Or
perhaps you found a bug.

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

I think they work like they are documented and implemented to work. They may
not match your use cases exactly.

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

I'll help you understand how libcurl works, then you can convert that into how
your app should behave or possibly suggest ways we can improve.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html