java.lang.OutOfMemoryError: Java heap space - Quarkus 1.10.5.Final

[NasrCH]

Describe the bug
Difference in memory consumption between version 1.8.3 and 1.10.*
It can result in an OutOfMemoryError on a simple unit test using the ApachDS library.

Expected behavior
Use of 300 MB of memory instead of 2 GB +
Build succes with the unit test.

Actual behavior

Running org.nch.GreetingResourceTest
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 42.689 sec <<< FAILURE!
org.nch.GreetingResourceTest  Time elapsed: 42.689 sec  <<< ERROR!
java.lang.OutOfMemoryError: Java heap space
	at java.util.Arrays.copyOf(Arrays.java:3332)
	at java.lang.AbstractStringBuilder.ensureCapacityInternal(AbstractStringBuilder.java:124)
	at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:448)
	at java.lang.StringBuilder.append(StringBuilder.java:136)
	at java.lang.StringBuilder.append(StringBuilder.java:131)
	at org.apache.directory.api.ldap.model.schema.registries.Registries.dumpUsing(Registries.java:1954)
	at org.apache.directory.api.ldap.model.schema.registries.Registries.addReference(Registries.java:2031)
	at org.apache.directory.api.ldap.model.schema.registries.helper.ObjectClassHelper.addToRegistries(ObjectClassHelper.java:81)
	at org.apache.directory.api.ldap.model.schema.registries.Registries.buildReference(Registries.java:690)
	at org.apache.directory.api.ldap.model.schema.registries.Registries.buildObjectClassReferences(Registries.java:815)
	at org.apache.directory.api.ldap.model.schema.registries.Registries.buildReferences(Registries.java:875)
	at org.apache.directory.api.ldap.model.schema.registries.Registries.clone(Registries.java:2578)
	at org.apache.directory.api.ldap.schemamanager.impl.DefaultSchemaManager.cloneRegistries(DefaultSchemaManager.java:200)
	at org.apache.directory.api.ldap.schemamanager.impl.DefaultSchemaManager.load(DefaultSchemaManager.java:589)
	at org.apache.directory.server.core.api.schema.registries.synchronizers.SchemaSynchronizer.add(SchemaSynchronizer.java:215)
	at org.apache.directory.server.core.api.schema.registries.synchronizers.RegistrySynchronizerAdaptor.add(RegistrySynchronizerAdaptor.java:188)
	at org.apache.directory.server.core.api.schema.SchemaPartition.add(SchemaPartition.java:266)
	at org.apache.directory.server.core.shared.partition.DefaultPartitionNexus.add(DefaultPartitionNexus.java:385)
	at org.apache.directory.server.core.api.interceptor.BaseInterceptor$1.add(BaseInterceptor.java:158)
	at org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:412)
	at org.apache.directory.server.core.journal.JournalInterceptor.add(JournalInterceptor.java:139)
	at org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:412)
	at org.apache.directory.server.core.changelog.ChangeLogInterceptor.add(ChangeLogInterceptor.java:113)
	at org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:412)
	at org.apache.directory.server.core.trigger.TriggerInterceptor.add(TriggerInterceptor.java:300)
	at org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:412)
	at org.apache.directory.server.core.event.EventInterceptor.add(EventInterceptor.java:220)
	at org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:412)
	at org.apache.directory.server.core.subtree.SubentryInterceptor.add(SubentryInterceptor.java:1014)
	at org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:412)
	at org.apache.directory.server.core.collective.CollectiveAttributeInterceptor.add(CollectiveAttributeInterceptor.java:134)
	at org.apache.directory.server.core.api.interceptor.BaseInterceptor.next(BaseInterceptor.java:412)

Results :

Tests in error: 
  org.nch.GreetingResourceTest: Java heap space

To Reproduce

code-with-quarkus.zip

Steps to reproduce the behavior:

1. mvn clean install

Environment (please complete the following information):

• Arc - make it possible to get interceptor bindings from #30-Ubuntu SMP Mon Apr 20 16:58:30 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
• openjdk version "1.8.0_232"
  OpenJDK Runtime Environment (build 1.8.0_232-8u232-b09-0ubuntu1~19.04.1-b09)
  OpenJDK 64-Bit Server VM (build 25.232-b09, mixed mode)
• Quarkus version or git rev : 1.10.5.Final
• Apache Maven 3.6.3
  Maven home: /opt/apache-maven-3.6.3
  Java version: 1.8.0_232, vendor: Private Build, runtime: /usr/lib/jvm/java-8-openjdk-amd64/jre
  Default locale: fr_FR, platform encoding: UTF-8
  OS name: "linux", version: "5.4.0-26-generic", arch: "amd64", family: "unix"

[gsmet]

Can you analyze things a bit and analyze a memory dump of your application?

Thanks.

[geoand]

I'll take a quick look

[geoand]

This happens because org.jboss.logmanager.handlers.DelayedHandler has been setup by io.quarkus.bootstrap.logging.InitialConfigurator even though the test is not a Quarkus test.

InitialConfiguration is loaded by org.jboss.logmanager.LogContext which is in turn is loaded because of the existence of slf4j-jboss-logmanager.
As the test never starts a quarkus application, the DelayedHandler just keeps accumulating log records and eventually fails with OOM.

There are a couple of options I see here:

1. Make InitialConfigurator somehow determine whether it's running in the context of Quarkus application or not. If it isn't, it won't set up the DelayedHandler at all.
2. The DelayedHandler could perhaps just drop the records after a certain threshold.

@dmlloyd WDYT?

[dmlloyd]

I'd prefer something like option 1, but the problem is that AFAIK there's no real way to determine whether the app is indeed a Quarkus app, and there is also no real way to communicate that to the configurator might be set up quite early in boot.

I guess that leaves option 2, which also stinks because you'd have to choose a fairly large limit in order to not lose legitimate messages at start. It's not a very clean solution.

Perhaps a third option could be to change the InitialConfigurator behavior to discard all log messages (and later, to support a simple configuration input in a similar way to the upstream LogManager project, though perhaps simpler), and have Quarkus generate a "real" InitialConfigurator which installs the DelayedHandler.

[geoand]

@dmlloyd wouldn't something like #14316 work?

[dmlloyd]

Sure, that could work.

[stuartwdouglas]

I just tested the reproducer and you can work around it by doing:

 <plugin>
     <artifactId>maven-surefire-plugin</artifactId>
     <version>${surefire-plugin.version}</version>
     <configuration>
       <systemPropertyVariables>
         <java.util.logging.manager>java.util.logging.LogManager</java.util.logging.manager>
         <maven.home>${maven.home}</maven.home>
       </systemPropertyVariables>
     </configuration>
   </plugin>

This basically tells Java to just use the standard logmanager instead of the JBoss one.

I don't think we can do any better than this, but I will see what others think before closing.

[geoand]

I spent too much time trying to come up with a solution and no good one seems to exist.
I think we just need to accept the fact and indeed just do something like you mention.

Furthermore the problem only shows up when only non Quarkus tests are executed - as soon as Quarkus test comes into play, it works.

I'm in favor of closing the issue and my (crappy) PR

[geoand]

I'll close this because we ended up adding an upper bound to the log entries