curl / Mailing Lists / curl-library / Single Mail

curl-library

Re: unexpected code 35 (if tcp listen backlog is full)

From: Michael Kilburn via curl-library <curl-library_at_cool.haxx.se>
Date: Tue, 16 Jan 2018 01:33:25 -0600

On Tue, Jan 16, 2018 at 1:09 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:

> On Mon, 15 Jan 2018, Michael Kilburn wrote:
>
> It doesn't seem to work for me -- I've crated a shared cache of easy
>> handles, after thread is done sending data, it returns handle (CURL*) into
>> cache (actually, stack). But on server side accept queue size is always
>> 20-30 while client is sending data (and performance has barely changed).
>>
>
> I'm sorry but I don't understand what you're trying to achieve nor how you
> do it.

Hmm... did I accidentally delete a portion of message? It is definitely
hard on eyes. My apologies :)

I've created a cache (an instance of std::stack<CURL*>) protected by mutex.
Each thread (in order to send data out) tries to get a handle from cache
first (and if not -- creates it using related libcurl function). Once
thread is done (with sending data) -- handle gets pushed into the cache.

curl_easy_setopt(CURLOPT_WRITEFUNCTION, ...) // func discards incoming
>> data
>>
>
> I trust this callback return the correct value still? Otherwise it'll
> probably cause the connection to get closed.
>

Yes, everything works as intended. Only problem is that (judging by accept
queue size) tcp connections and (judging by high CPU usage) TLS sessions
don't get reused.

> curl_easy_perform()
>>
>
> In the easy interface (that you are using when _easy_perform is called),
> the connection cache is held in the easy handle so unless you share the
> connection cache between handles you must make sure to re-use a handle that
> was previously used to communicate with the same host as otherwise it won't
> have the previous connection in its cache...

all threads talk to the same server (same url). I expected that if I reuse
easy handles between my "post_data()" invocations -- it'll lead to reuse of
underlying tcp connection (and TLS sessions).

> Maybe one of these options prevent tcp connection (and related TLS session
>> key) from being reused?
>>
>
> Connections can also get closed by the server's decisions.

You might have solved my problem right here. I am testing all this
using BaseHTTPServer and ssl python modules -- it is quite likely
BaseHTTPServer closes connection after each POST.

I bet ssl module doesn't support TLS session caching too. Good thing in
prod environment I have a real web server. Hmm... need to figure out how to
ensure both caching mechanisms are ON.

Thank you for help, Daniel.

Regards,
Michael.

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-01-16