Re: connection pooling?
Date: Tue, 08 Jan 2002 10:41:45 -0500
>>Each "easy-handle" keeps the last N connections open and alive if possible
>>for persistant connection reasons. Thus, you probably want to re-use the
>>same handle again when re-issuing a request to a host a second time...
if I kept the same easy _handle hanging around, does it know if a connection
is in-use or not? Should I (can I) be inspecting the connections on the
curl_handle for availability?
>From: Daniel Stenberg <daniel_at_haxx.se>
>To: rick vaillancourt <rick_vaillancourt_at_hotmail.com>
>CC: libcurl Mailing list <curl-library_at_lists.sourceforge.net>
>Subject: Re: connection pooling?
>Date: Tue, 8 Jan 2002 16:30:01 +0100 (MET)
>On Tue, 8 Jan 2002, rick vaillancourt wrote:
> > I have a C++ service that wants to make a url call to get some data from
> > another service...
> > I figured rather than incuring the hit of init every time, I could go at
> > cached curl_handle?
>That could make sense. No matter if you pool handles or not, curl is always
>best used when not doing cleanup/init but instead just re-using the same
>handle over and over again.
> > I was thinking of creating some kind of factory class that had like 10
> > init'd curl_handles and a state flag available/notavailable.
> > C++ service asks factory for first available curl_handle and makes the
> > call.
>There might be reasons why you need to consider how you go ahead and
>Each "easy-handle" keeps the last N connections open and alive if possible
>for persistant connection reasons. Thus, you probably want to re-use the
>same handle again when re-issuing a request to a host a second time...
>Doing this with many requests for each handle may also result in quite a
>large number of connections kept alive, which isn't a problem as long as
>you're aware of it.
> > I wanted to check if someone had something like that out there already.
>Not that I know of.
> Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/
Chat with friends online, try MSN Messenger: http://messenger.msn.com
Received on 2002-01-08