Re: Failed sending data to the peer in 7.72.0
Date: Mon, 14 Sep 2020 14:38:56 -0700
Unfortunately, it takes rather several hours of running to identify this
failure; building a new package and bisecting is going to be quite
difficult with that long of a turnaround.
I however was able to get a tcpdump of one of the affected sessions.
This session spans several requests to the same backend (Typhoeus pools
curl sockets and tries to use keep-alive whenever possible). The first few
requests succeed; at some point there's a ~9-second break in requests while
the process does other stuff and the server closes the TCP stream (our load
balancer is configured to close idle keep-alive sessions after 9 seconds).
Within a few milliseconds, another request is sent on the same socket; it
immediately gets back a RST because the server has already closed this
socket. That appears to cause this exception to be raised by libcurl.
Did anything change around handling keep-alive session expiry in HTTP/1.1
mode? Nothing jumps out at me in the git log (there's something in the
schannel backend, but I'm on Linux; there's also d5bb459ccf
<https://github.com/curl/curl/commit/d5bb459ccf1fc5980ae4b95c05b4ecf6454a7599>
which
claims to only affect CONNECT-only connections, and all of this is regular
GETs and POSTs)...
On Fri, Sep 11, 2020 at 10:34 PM Ray Satiro via curl-library <
curl-library_at_cool.haxx.se> wrote:
> On 9/11/2020 2:03 PM, James Brown via curl-library wrote:
>
> After upgrading a test cluster from 7.71.1 to 7.72.0, we're now seeing
> around 0.1% of POSTs from one (and only one) of our applications fail with
> "Failed sending data to the peer" (CURLE_SEND_ERROR) and no other error.
> Based on logs, the request actually succeeds, but libcurl is returning this
> error. This application is using the Ruby Typhoeus wrapper and is itself
> unchanged. The relevant connections are all HTTP/1.1 connections to hosts
> on the local network, and the POSTs are all very small (<1KB) with nothing
> interesting about them.
>
> I haven't had any luck tracking this down since it's such a low fraction
> of requests and is only affecting one of our several hundred applications,
> but it reproducibly happens with 7.72 and not with 7.71.1.
>
> Anyone have any suggestions for how to try to track down the regression? I
> looked at the diff between 7.71.1 and 7.72.0 and no lines containing the
> string "CURLE_SEND_ERROR" were touched, which is unfortunate.
>
>
> There are no similar reports and I looked through the commit history but
> nothing stood out. If you can reliably reproduce then try bisecting it
> https://github.com/curl/curl/wiki/how-to-git-bisect
>
>
> -------------------------------------------------------------------
> Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
> Etiquette: https://curl.haxx.se/mail/etiquette.html
-- James Brown Engineer
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2020-09-14