https://sourceware.org/bugzilla/show_bug.cgi?id=28708
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 on 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 those
threads. When a new connection comes in, it seems to be just luck as to which
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 exist
with much larger available connection limits, but they are not consulted.)
This is probably why Mark's experimental MHD_OPTION_CONNECTION_LIMIT set helped
(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.
--
You are receiving this mail because:
You are on the CC list for the bug.
