java-kafka-clients fails test on CI

OpenSubmitted by Marius Bakke.
Details
2 participants
  • Björn Höfling
  • Marius Bakke
Owner
unassigned
Severity
normal
Merged with
M
M
Marius Bakke wrote on 19 Apr 18:22 +0200
(address . bug-guix@gnu.org)
875zdvh2d4.fsf@devup.no
Hello,
'java-kafka-clients' fails to build on Berlin:
https://ci.guix.gnu.org/log/9ky8skd03p7yvik2dms2h6d7l7fsc6cv-java-kafka-clients-1.0.0
The failing test is"org.apache.kafka.common.memory.GarbageCollectedMemoryPoolTest",possibly because of the large amount of memory on the CI machines.
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAl6cescACgkQoqBt8qM6VPoVvwgAmUKWYSbg8z4EUbVXaE2Dy3YCbRM0g7iwlDxda2Xa3tZF/pJtvUS6eb9vTkwV8P1sHG3Zfp7agZ7TImqyOyi4KVBftuy/8VkmI1bYi4buEe9jmfTtr/cjF+1qyaEMtR1q0OhgnX5tYOKymeP8oKQE1Dt6w1pdJw22tSg2J1LB2twm5HKkII2kiA1lTnlGA+FsVaqb2ZWa7idTLDgt7BJkR8on6VyngQ0GefrRKiAzF2DOcWyY48DiKYrGy528ioJD146Rk0AH8bYprzcAkiWFmkEMnx1bB0SaGCWOAS9wb+oyFtKMxK9v9WcKdkmjNIEkJeoWx1Qqtoj0Pm7Kk4ylsg===ZKla-----END PGP SIGNATURE-----
B
B
Björn Höfling wrote on 28 Apr 19:58 +0200
merge 40554 40718
(address . control@debbugs.gnu.org)
20200428195835.12c2a421@alma-ubu
merge 40554 40718end
-----BEGIN PGP SIGNATURE-----
iF0EARECAB0WIQQiGUP0np8nb5SZM4K/KGy2WT5f/QUCXqhuywAKCRC/KGy2WT5f/ZEhAJ0TpkyDSNS+vo3jfpzYY+X924FKeACfephLgWRRkIraxCle2em19OBVXRk==xA5x-----END PGP SIGNATURE-----

B
B
Björn Höfling wrote on 30 Apr 00:47 +0200
Re: bug#40718: java-kafka-clients fails test on CI
(name . Marius Bakke)(address . mbakke@fastmail.com)(address . 40718@debbugs.gnu.org)
20200430004716.30b8dd82@alma-ubu
On Sun, 19 Apr 2020 18:22:31 +0200Marius Bakke <mbakke@fastmail.com> wrote:
Toggle quote (10 lines)> Hello,> > 'java-kafka-clients' fails to build on Berlin:> > https://ci.guix.gnu.org/log/9ky8skd03p7yvik2dms2h6d7l7fsc6cv-java-kafka-clients-1.0.0> > The failing test is> "org.apache.kafka.common.memory.GarbageCollectedMemoryPoolTest",> possibly because of the large amount of memory on the CI machines.
Hi Marius,
I merged your 40554 and 40718 which stated the same bug within a week.Or did I miss a difference?
The easiest thing probably would be to just turn off the failingtest.Instead I tried to investigate this bug, but with little successyet. Here are my findings:
Locally it always built fine.
Due to #40966 my trust in CI results faded a bit away.
When searching for java-kafka-clients, I sometimes see also successfulbuilds:
https://ci.guix.gnu.org/search?query=java-kafka-clients++system%3Ax86_64-linux+spec%3Aguix-master
(Hit reload several times)Yesterday I thought I saw it going red only 3 weeks ago, but now Idon't have that clear picture any more. The search results are strange.
LOGGING:
On the JUnit output, I saw lines like this:
[junit] SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". [junit] SLF4J: Defaulting to no-operation (NOP) logger implementation [junit] SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinderfor further details.
In order to get logging, I added a logger implementation as nativeinput:
++ ("java-sl4fj-simple" ,java-slf4j-simple)
That showed some output on the console. Maybe that could help find theissue?
Unfortunately, java-slf4j-simple fails to build on berlin, too(locally, it built fine)...
MEMORY SIZE:
I modified the sources of the JUnit test to print out the actual memoryusage during test execution, and built that with the "--sources=..."option. But that's nothing we can do on berlin. Or would there be anadministrator trying it out on their local account?
I wanted to change the heap size during tests on my computer with the"ANT_OPTS" environment variable, where you could pass a "-Xmx=16G"option or something. That did not have any effect on the reported heapsize. Problem is, that our generated build.xml file has a
<junit fork="yes" ...>
line, which is in general a good idea, but meaning that tests areexecuted under a new JVM other than ANT. We either need to sayfork="no" (I'm currently rebuilding the JVM-world with that) or we haveto give here an additional option "maxmemory".
BUILD GRAPH:
When looking at the reverse-dependency graph, you notice that onlyjava-log4j-core is using it directly. Can we get rid of that edge?On the master of log4j, there is a separate module for theKafka-Appender, but it is not in any stabl release.
Björn
-----BEGIN PGP SIGNATURE-----
iF0EARECAB0WIQQiGUP0np8nb5SZM4K/KGy2WT5f/QUCXqoD9AAKCRC/KGy2WT5f/e86AJ9zKJ/AMFPRnttU7xU+YoAWhYIczwCfeF5uxYcQ8wv9IE8izS+36zrMmVw==yzwZ-----END PGP SIGNATURE-----

M
M
Marius Bakke wrote on 19 May 20:17 +0200
Re: bug#41396: java-kafka-clients fails tests
87pnazrdqa.fsf@devup.no
merge 41396 40718thanks
Ricardo Wurmus <rekado@elephly.net> writes:
Toggle quote (10 lines)> java-kafka-clients has a failing test:>> [junit] Running org.apache.kafka.common.network.SslTransportLayerTest> [junit] SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".> [junit] SLF4J: Defaulting to no-operation (NOP) logger implementation> [junit] SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.> [junit] Tests run: 31, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 8.072 sec>> The SLF4J failure seems to be unrelated (other tests also have this warning).
It only seems to happen on big-memory systems (but consistently so).Björn did some investigation here:
https://issues.guix.gnu.org/40718#2
If you can reproduce it, please help! :-)
?