ClassGraph raised OOM error in my project

[hantsy]

My project is based on Spring Boot 3/R2dbc + Kotlin/KotlinCoroutines + Java 17(set Language Level to 17). I am using the latest 2.0.2 in my project.

The source codes archived 100k lines now.

In the newest feature branch, I always encountered an OutOfMemoery error when running tests on Github Actions, even I used a custom larger runner with 4 core + 16G and increased the Gralde jvm args to use a larger heap size(4G, 8G, 12G) to build the project. It is 100% failed due to the OOM error.

There is a question I posted on StackOverFlow, https://stackoverflow.com/questions/75169922/outofmemoryerror-in-gradle-springboot-kotlin-coroutines-project

Today I tried to remove Spring Doc config, and spring-doc dep, it works. And the build progress is shorten to 75%, and saved 2 min.

I am not sure why if ClassGraph is a must for springdoc, Spring itself scan all beans at runtime. Why we need another scanner in the background and finally kill the application.

[hantsy]

I tried to add global packageToScan to the application.properties to limit the scan scope to all controllers, but it still failed of OOM.

A question here, by default I have disabled spring doc(springdoc.api-docs.enabled and springdoc.swagger-ui.enabled), and also use ConditionalOnProperty to disable the SpringDoc configuration class.
It sill failed of OOM(caused by ClassGraph), why it still scan the classes info in the background?

[hantsy]

Today I tried to add packageToScan to every groupedOpenAPI beans, there are several GroupedOpenAPI beans in our project, still encountered the same error(OOM).

[hantsy]

I wonder why ClassGraph is scanning class infos in the background even I disable springdoc.

[bnasslahsen]

@hantsy,

This is ClassGraph question.
It should be addressed here instead https://github.com/classgraph/classgraph/issues

[hantsy]

@bnasslahsen It seems you did not read all of my messages.

I have discussed with the ClassGraph guys firstly, they confirmed it is related to the project and how to use it. So I created an issue here.

classgraph/classgraph#751

I extracted the explanation from the ClassGraph guys.

If your library is indiscriminately scanning the entire classpath, and storing ClassInfo objects for every class encountered, then yes, ClassGraph can consume a large amount of RAM. The fix is probably to modify the library to scan the smallest set of classes possible.

OK, well you need to file a bug with springdoc then, ClassGraph only scans what it is told to scan.

Obviously, I disabled springdoc in application.properties, the ClassGraph still scans at every Spring context setup phase in the tests. This is unreasonable.

And setup scan scopes in every grouped OpenAPI beans, it also does not stop the OOM. If the packagesToScan did not limit to scan a small mount of classes, what is it means here?

GroupedOpenApi.builder()
    .group("myGroup")
    .pathsToMatch(*paths)
    .packagesToScan("com.example")
    ...

[bnasslahsen]

@hantsy,

I invite you to check deeper.
In the springdoc code, there are no explicite calls to ClassGraph.

Try just référencing the swagger-core and swagger-ui directly to confirm the root library cause of your error.

[hantsy]

In the springdoc code, there are no explicit calls to ClassGraph.

So it can be removed?

But from the project dependency tree, spring doc depends on it directly.

[bnasslahsen]

@hantsy,

Classgraph is required by webjars-locator-core

This dependency is only required for the UI to hide the UI version from the URL.

Basically, if you don't reference the SWAGGER-UI, it will not be added.
You can exclude org.webjars:webjars-locator-core from the dependencies, and try:
springdoc.enable-native-support=true

You will see in the URL, the version of the swagger-ui.

If you are still having issues, you will need to Provide a Minimal, Reproducible Example - with HelloController that reproduces the problem

[hantsy]

Of course I would like provide a small example project to produce the errors, but I found it is only occurred when there are a bundle of classes existed in the project.

I noticed there is a PR to review webjar-locator-core #2173, hope it resolve my issue.

[bnasslahsen]

@hantsy,

You can try with the latest SNAPSHOT and provide your feedback.