java-kafka-clients fails test on CI

  • Open
  • quality assurance status badge
Details
2 participants
  • Björn Höfling
  • Marius Bakke
Owner
unassigned
Submitted by
Marius Bakke
Severity
normal
Merged with
M
M
Marius Bakke wrote on 19 Apr 2020 18:22
(address . bug-guix@gnu.org)
875zdvh2d4.fsf@devup.no
Hello,

'java-kafka-clients' fails to build on Berlin:


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-----

iQEzBAEBCgAdFiEEu7At3yzq9qgNHeZDoqBt8qM6VPoFAl6cescACgkQoqBt8qM6
VPoVvwgAmUKWYSbg8z4EUbVXaE2Dy3YCbRM0g7iwlDxda2Xa3tZF/pJtvUS6eb9v
TkwV8P1sHG3Zfp7agZ7TImqyOyi4KVBftuy/8VkmI1bYi4buEe9jmfTtr/cjF+1q
yaEMtR1q0OhgnX5tYOKymeP8oKQE1Dt6w1pdJw22tSg2J1LB2twm5HKkII2kiA1l
TnlGA+FsVaqb2ZWa7idTLDgt7BJkR8on6VyngQ0GefrRKiAzF2DOcWyY48DiKYrG
y528ioJD146Rk0AH8bYprzcAkiWFmkEMnx1bB0SaGCWOAS9wb+oyFtKMxK9v9WcK
dkmjNIEkJeoWx1Qqtoj0Pm7Kk4ylsg==
=ZKla
-----END PGP SIGNATURE-----

B
B
Björn Höfling wrote on 28 Apr 2020 19:58
merge 40554 40718
(address . control@debbugs.gnu.org)
20200428195835.12c2a421@alma-ubu
merge 40554 40718
end
-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQQiGUP0np8nb5SZM4K/KGy2WT5f/QUCXqhuywAKCRC/KGy2WT5f
/ZEhAJ0TpkyDSNS+vo3jfpzYY+X924FKeACfephLgWRRkIraxCle2em19OBVXRk=
=xA5x
-----END PGP SIGNATURE-----


B
B
Björn Höfling wrote on 30 Apr 2020 00:47
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 +0200
Marius 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 failing
test.Instead I tried to investigate this bug, but with little success
yet. 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 successful
builds:


(Hit reload several times)
Yesterday I thought I saw it going red only 3 weeks ago, but now I
don'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 native
input:

++ ("java-sl4fj-simple" ,java-slf4j-simple)

That showed some output on the console. Maybe that could help find the
issue?

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 memory
usage during test execution, and built that with the "--sources=..."
option. But that's nothing we can do on berlin. Or would there be an
administrator 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 heap
size. 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 are
executed under a new JVM other than ANT. We either need to say
fork="no" (I'm currently rebuilding the JVM-world with that) or we have
to give here an additional option "maxmemory".

BUILD GRAPH:

When looking at the reverse-dependency graph, you notice that only
java-log4j-core is using it directly. Can we get rid of that edge?
On the master of log4j, there is a separate module for the
Kafka-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 2020 20:17
Re: bug#41396: java-kafka-clients fails tests
87pnazrdqa.fsf@devup.no
merge 41396 40718
thanks

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:


If you can reproduce it, please help! :-)
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 40718@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 40718
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch