quarkus: Java OOM Java heap space when I use WithKubernetesTestServer annotation in unit test

Describe the bug

We use in our unit tests @QuarkusTestResource(KubernetesServerTestResource.class) and all unit tests works fine with this mocked kube server, but we want to have scope of mocked kube server per class instead of per module so we switched to @WithKubernetesTestServer which is equivalent to @QuarkusTestResource(value = KubernetesServerTestResource.class, restrictToAnnotatedClass = true) and test run fails on OOM after some time of surefire run.

Expected behavior

Uni tests pass

Actual behavior

Tests fail after some time on OOM Java Heap space

How to Reproduce?

Run more unit tests from more classes with mocked kube server like we do in our unit tests

Output of uname -a or ver

Darwin dkornel-mac 20.6.0 Darwin Kernel Version 20.6.0: Wed Jun 23 00:26:27 PDT 2021; root:xnu-7195.141.2~5/RELEASE_ARM64_T8101 arm64

Output of java -version

openjdk version “11.0.11” 2021-04-20 OpenJDK Runtime Environment AdoptOpenJDK-11.0.11+9 (build 11.0.11+9) OpenJDK 64-Bit Server VM AdoptOpenJDK-11.0.11+9 (build 11.0.11+9, mixed mode)

GraalVM version (if different from Java)

No response

Quarkus version or git rev

1.13.1.Final

Build tool (ie. output of mvnw --version or gradlew --version)

Apache Maven 3.8.1 (05c21c65bdfed0f71a2f2ada8b84da59348c4c5d)

Additional information

surefire version: maven-surefire-plugin:3.0.0-M5

Test log run https://gist.github.com/kornys/f08ca9041c01b551af77631ff38dcd64

Error stack trace

java.lang.RuntimeException: io.quarkus.builder.BuildException: Build failure: Build failed due to errors
Error: ]: Build step io.quarkus.deployment.steps.ConfigGenerationBuildStep#generateConfigClass threw an exception: java.lang.OutOfMemoryError: Java heap space
	at io.quarkus.gizmo.BytecodeCreatorImpl.invokeVirtualMethod(BytecodeCreatorImpl.java:121)
	at io.quarkus.deployment.configuration.RunTimeConfigurationGenerator$GenerateOperation.generateParserBody(RunTimeConfigurationGenerator.java:1237)
	at io.quarkus.deployment.configuration.RunTimeConfigurationGenerator$GenerateOperation.generateParserBody(RunTimeConfigurationGenerator.java:1186)
	at io.quarkus.deployment.configuration.RunTimeConfigurationGenerator$GenerateOperation.generateParserBody(RunTimeConfigurationGenerator.java:1186)
	at io.quarkus.deployment.configuration.RunTimeConfigurationGenerator$GenerateOperation.generateParserBody(RunTimeConfigurationGenerator.java:1186)
	at io.quarkus.deployment.configuration.RunTimeConfigurationGenerator$GenerateOperation.run(RunTimeConfigurationGenerator.java:462)
	at io.quarkus.deployment.configuration.RunTimeConfigurationGenerator.generate(RunTimeConfigurationGenerator.java:249)
	at io.quarkus.deployment.steps.ConfigGenerationBuildStep.generateConfigClass(ConfigGenerationBuildStep.java:63)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at io.quarkus.deployment.ExtensionLoader$2.execute(ExtensionLoader.java:920)
	at io.quarkus.builder.BuildContext.run(BuildContext.java:277)
	at io.quarkus.builder.BuildContext$$Lambda$2710/0x00000001014f1840.run(Unknown Source)
	at org.jboss.threads.EnhancedQueueExecutor$Task.run(EnhancedQueueExecutor.java:2415)
	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1452)
	at java.base/java.lang.Thread.run(Thread.java:829)
	at org.jboss.threads.JBossThread.run(JBossThread.java:501)

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 41 (38 by maintainers)

Commits related to this issue

Most upvoted comments

Is there any chance you can bump the project to the latest Quarkus version (I tried and something doesn’t compile)

That’s usually an involved process - we need to keep the quarkus / fabric8 / operator sdk versions in lock step. I can try updating to the latest operator sdk in another branch to give you a better starting point.