Hi Daniel,

This problem had vanished for a while. We've started seeing it again now.

To give you a synopsis, Swift Foundation library's URLSession
implementation uses libcurl under the hood. In this failing test, we do a
series of API calls to the api.github.com endpoint (with connection reuse).
During one of these calls (randomly) the connection is closed.

As you mention in your previous response, this may not be a libcurl issue.
I'm only interested in what exactly is happening here! I enabled libcurl
traces and ran with a debug libcurl (latest source from github). This is
what I see just before the connection is closed. Can you please help us
understand what these stand for?

[466] Re-using existing connection! (#0) with host api.github.com␊

[466] Connected to api.github.com (192.30.253.116) port 443 (#0)␊

[466] STATE: CONNECT => DO handle 0x7f0b3045d348; line 1464
(connection #0)␊

[466] Operation timed out after 0 milliseconds with 0 out of 0
bytes received␊

[466] multi_done␊

[466] Closing connection 0␊

[466] The cache now contains 1 members␊

[466] => Send SSL data ␕␃␃␀␚

[466] TLSv1.2 (OUT), TLS alert, Client hello (1):␊

[466] => Send SSL data ␁␀

Thanks!

Pushkar

On Thu, Dec 15, 2016 at 8:58 PM, Daniel Stenberg <daniel_at_haxx.se> wrote:

> On Wed, 14 Dec 2016, Pushkar Kulkarni wrote:
>
> There's an issue where we make ~180 GET calls to the *same endpoint* (the
>> GitHub API). Internally, for each GET call we seem to be configuring an
>> easy handle and then registering it with a multi handle. In one of these
>> iterations (randomly), I see libcurl returning CURLE_CANNOT_CONNECT.
>>
>
> That's a failure to connect(). Are you sure this is a libcurl problem and
> simply not the server for example saying no to your attempts?
>
> So, I turned on the verbose mode and before each transfer I could see this:
>> [1] Connection #0 to host api.github.com left intact
>>
>> Only, before the failing connection, I see:
>> [1] Connection #0 to host api.github.com left intact
>> [1] Closing connection 0`
>>
>
> Right that makes perfect sense because if it reuses the connection it
> won't have to do another connect attempt. Only if it actualy closed the
> previous connection it will connect again and then risk failing that.
>
> Nothing else is logged on failure. When I try to use strace, to find the
>> failing system call, the failure gets masked.
>>
>> I am not sure how to proceed with the analysis. Can someone please help
>> me take this further, please?
>>
>
> If you build a debug version of the library it will give you clues to why
> the connection is closed, which could be a good step towards figuring this
> out.
>
> --
>
> / daniel.haxx.se
> -------------------------------------------------------------------
> List admin: https://cool.haxx.se/list/listinfo/curl-library
> Etiquette: https://curl.haxx.se/mail/etiquette.html

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2017-02-23