Java OOM Java heap space when I use WithKubernetesTestServer annotation in unit test
See original GitHub issueDescribe 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)
Issue Analytics
- State:
- Created 2 years ago
- Comments:29 (26 by maintainers)
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.
We’re facing the same issue with Quarkus 2.7.4. Increasing maxHeapSize in Gradle works, but is there any other way to avoid failing tests because of
java.lang.OutOfMemoryError: Java heap space
exceptions?