limit. Closing inbound
connection." issue we have been seeing in the
run-debuginfod-webapi-concurrency.sh testcase. From the manual:
If the connection limit is reached, MHD’s behavior depends a bit
on other options. If MHD_USE_ITC was given, MHD will stop
accepting conn
E-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This prevents the "Server reached connection limit. Closing inbound
connection." issue we have been seeing in the
run-debuginfod-webapi-concurrency.sh testcase. From the manual:
If the connection lim
Hi,
"Frank Ch. Eigler" writes:
>> But there is another way to prevent the "Server reached connection
>> limit. Closing inbound connection." Pass the MHD_USE_ITC flag to
>> MHD_start_daemon:
>
> Yeah, that looked promising to me too. When I was last working on
> this, that would have been my nex
Hi -
> But there is another way to prevent the "Server reached connection
> limit. Closing inbound connection." Pass the MHD_USE_ITC flag to
> MHD_start_daemon:
Yeah, that looked promising to me too. When I was last working on
this, that would have been my next thing to try. I can't think of
a
ided by the number of
threads in the daemon threadpool.
So one way to fix this is to lower the max number of -C THREADS::
diff --git a/tests/run-debuginfod-webapi-concurrency.sh
b/tests/run-debuginfod-webapi-concurrency.sh
index 4928f6d0..12b460a8 100755
--- a/tests/run-debuginfod-webapi-concurren
Hi -
> [...]
> I think that might be Frank's local experimentation. I also got email
> about my workers being unavailable. If you run a buildbot locally it
> will not see any workers connect and after an hour it will try to
> notify the owners.
Sorry about that. After this noisy testing, I pushe
"} 35
And sadly I have also been able to replicate that on another s390x setup even
with all the latest patches.
The thing they seem to have in common is that they are both s390x and have only
2 cores.
If I lower the -C100 to -C32 in run-debuginfod-webapi-concurrency.sh it does
seem to a
https://sourceware.org/bugzilla/show_bug.cgi?id=28708
--- Comment #12 from Evgeny Vereshchagin ---
FWIW with
https://sourceware.org/git/?p=elfutils.git;a=commit;h=e646e363e72e06e0ed5574c929236d815ddcbbaf
applied the test appears to be flaky on Packit on s390x:
https://copr-be.cloud.fedoraproject.
https://sourceware.org/bugzilla/show_bug.cgi?id=28708
Frank Ch. Eigler changed:
What|Removed |Added
Status|WAITING |ASSIGNED
--- Comment #11 from Fran
https://sourceware.org/bugzilla/show_bug.cgi?id=28708
--- Comment #10 from Evgeny Vereshchagin ---
(In reply to Mark Wielaard from comment #9)
> (In reply to Evgeny Vereshchagin from comment #7)
> > > Note that packit doesn't use real hardware for various architectures but
> > > "container emulat
https://sourceware.org/bugzilla/show_bug.cgi?id=28708
--- Comment #9 from Mark Wielaard ---
(In reply to Evgeny Vereshchagin from comment #7)
> > Note that packit doesn't use real hardware for various architectures but
> > "container emulation" which causes various testcases to fail.
> >
> I thi
https://sourceware.org/bugzilla/show_bug.cgi?id=28708
--- Comment #8 from Frank Ch. Eigler ---
This test creates up to 100+few threads in debuginfod, and also 100 concurrent
curl processes to talk to debuginfod.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://sourceware.org/bugzilla/show_bug.cgi?id=28708
--- Comment #7 from Evgeny Vereshchagin ---
> Note that packit doesn't use real hardware for various architectures but
> "container emulation" which causes various testcases to fail.
>
I think I ran into issues like that in
https://github.co
https://sourceware.org/bugzilla/show_bug.cgi?id=28708
Frank Ch. Eigler changed:
What|Removed |Added
Status|NEW |WAITING
--
You are receiving this
https://sourceware.org/bugzilla/show_bug.cgi?id=28708
--- Comment #5 from Frank Ch. Eigler ---
(In reply to Mark Wielaard from comment #4)
> Note that packit doesn't use real hardware for various architectures but
> "container emulation" which causes various testcases to fail.
>
> Although in thi
https://sourceware.org/bugzilla/show_bug.cgi?id=28708
--- Comment #5 from Frank Ch. Eigler ---
(In reply to Mark Wielaard from comment #4)
> Note that packit doesn't use real hardware for various architectures but
> "container emulation" which causes various testcases to fail.
>
> Although in thi
https://sourceware.org/bugzilla/show_bug.cgi?id=28708
Mark Wielaard changed:
What|Removed |Added
CC||mark at klomp dot org
--- Comment #4
https://sourceware.org/bugzilla/show_bug.cgi?id=28708
--- Comment #3 from Evgeny Vereshchagin ---
I think they are constrained in the sense that those machines are much slower
than usual. On top of that the packages are built in a sandbox environment and
that makes them even slower.
--
You are
https://sourceware.org/bugzilla/show_bug.cgi?id=28708
Frank Ch. Eigler changed:
What|Removed |Added
Last reconfirmed||2021-12-17
CC|
https://sourceware.org/bugzilla/show_bug.cgi?id=28708
--- Comment #1 from Evgeny Vereshchagin ---
Created attachment 13859
--> https://sourceware.org/bugzilla/attachment.cgi?id=13859&action=edit
full log
Just in case, I've just attached the full log.
--
You are receiving this mail because:
Y
https://sourceware.org/bugzilla/show_bug.cgi?id=28708
Bug ID: 28708
Summary: run-debuginfod-webapi-concurrency.sh seems to be flaky
Product: elfutils
Version: unspecified
Status: UNCONFIRMED
Severity: normal
Priority: P2
21 matches
Mail list logo
