[Bug debuginfod/27859] New: reused debuginfod_client objects don't clean out curl handles enough

[Bug debuginfod/27859] New: reused debuginfod_client objects don't clean out curl handles enough

[fche at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27859

            Bug ID: 27859
           Summary: reused debuginfod_client objects don't clean out curl
                    handles enough
           Product: elfutils
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: debuginfod
          Assignee: fche at redhat dot com
          Reporter: fche at redhat dot com
                CC: elfutils-devel at sourceware dot org
  Target Milestone: ---

Not long after deploying the new 0.184 release in anger, amerey noticed that it
was possible for a federating debuginfod to report 404's on queries that its
upstream can readily satisfy.  Further digging and testing indicates that this
is not related to the 000 negative caching, but rather some sort of
error-latching effect with the curl handles.

In a sequence of queries on the same debuginfod_client, as long as they are all
successful, things are fine.  Once there is a 404 error however, this appears
to latch, and subsequent requests give 404 whether or not they were resolvable
by upstream.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug debuginfod/27859] reused debuginfod_client objects don't clean out curl handles enough

[fche at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27859

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://sourceware.org/bugz
                   |                            |illa/show_bug.cgi?id=27701

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: [Bug debuginfod/27859] New: reused debuginfod_client objects don't clean out curl handles enough

[Mark Wielaard]

On Thu, May 13, 2021 at 01:26:42AM +0000, fche at redhat dot com via Elfutils-devel wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=27859
>
> In a sequence of queries on the same debuginfod_client, as long as
> they are all successful, things are fine.  Once there is a 404 error
> however, this appears to latch, and subsequent requests give 404
> whether or not they were resolvable by upstream.

Makes sense that curl remembers 404 results. Does that mean we need to
refresh the curl handle when a request is made for a negative cached
entry and cache_miss_s expires?

[Bug debuginfod/27859] reused debuginfod_client objects don't clean out curl handles enough

[mark at klomp dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=27859

--- Comment #1 from Mark Wielaard <mark at klomp dot org> ---
On Thu, May 13, 2021 at 01:26:42AM +0000, fche at redhat dot com via
Elfutils-devel wrote:
> https://sourceware.org/bugzilla/show_bug.cgi?id=27859
>
> In a sequence of queries on the same debuginfod_client, as long as
> they are all successful, things are fine.  Once there is a 404 error
> however, this appears to latch, and subsequent requests give 404
> whether or not they were resolvable by upstream.

Makes sense that curl remembers 404 results. Does that mean we need to
refresh the curl handle when a request is made for a negative cached
entry and cache_miss_s expires?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug debuginfod/27859] reused debuginfod_client objects don't clean out curl handles enough

[fche at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=27859

Frank Ch. Eigler <fche at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #2 from Frank Ch. Eigler <fche at redhat dot com> ---
commit 0b454c7e1997 fixes this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.