From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <sourceware-bugzilla@sourceware.org>
Received: by sourceware.org (Postfix, from userid 48)
 id A03AA3858C53; Sun,  3 Apr 2022 00:43:01 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A03AA3858C53
From: "fche at redhat dot com" <sourceware-bugzilla@sourceware.org>
To: elfutils-devel@sourceware.org
Subject: [Bug debuginfod/28708] run-debuginfod-webapi-concurrency.sh seems to
 be flaky
Date: Sun, 03 Apr 2022 00:43:01 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: elfutils
X-Bugzilla-Component: debuginfod
X-Bugzilla-Version: unspecified
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: fche at redhat dot com
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at sourceware dot org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: bug_status
Message-ID: <bug-28708-10460-iW0RVRvwSH@http.sourceware.org/bugzilla/>
In-Reply-To: <bug-28708-10460@http.sourceware.org/bugzilla/>
References: <bug-28708-10460@http.sourceware.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://sourceware.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: elfutils-devel@sourceware.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Elfutils-devel mailing list <elfutils-devel.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/elfutils-devel>,
 <mailto:elfutils-devel-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/elfutils-devel/>
List-Help: <mailto:elfutils-devel-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/elfutils-devel>,
 <mailto:elfutils-devel-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Apr 2022 00:43:01 -0000

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |ASSIGNED

--- Comment #11 from Frank Ch. Eigler <fche at redhat dot com> ---
OK some findings, when a similar sounding problem intermittently occurred o=
n an
s390x VM.

It seems that we were expecting too much of libmicrohttpd.

When it offers a thread-pool (which we trigger in debuginfod via the -Cnnn
option), it splits a hypothetical concurrent-connection limit amongst all t=
hose
threads.  When a new connection comes in, it seems to be just luck as to wh=
ich
thread gets woken up.  And if that thread has some active connections still
(such as from previous transmission operations that were enqueued previously
and still in progress), then the new connection may go over its private
daemon->connection_limit and fail.  (At the same time, many threads may exi=
st
with much larger available connection limits, but they are not consulted.)

This is probably why Mark's experimental MHD_OPTION_CONNECTION_LIMIT set he=
lped
(1000ish->4000ish), because then dividing all those limits among the 100ish
threads leaves 40 each to work from rather than 10.

Investigating some microhttpd modes/options that may trigger more favourable
behaviour.  But if nothing appears, we may just need to turn down the tight
expectations of this test case.

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