Too many non-blocking read actions submitted at once in LSPDiagnosticHandler

[mfortunat]

Guys, the newly released version 1.24.0.508 has another, repeating, issue.
IJ version is: "Build #IU-232.8660.185, built on July 26, 2023"

Stack trace:

java.lang.Throwable: Too many non-blocking read actions submitted at once. Please use coalesceBy, BoundedTaskExecutor or another way of limiting the number of concurrently running threads.: 11 with similar stack traces are currently active
at com.intellij.openapi.diagnostic.Logger.error(Logger.java:370)
at com.intellij.openapi.application.impl.SubmissionTracker.preventTooManySubmissions(SubmissionTracker.java:45)
at com.intellij.openapi.application.impl.NonBlockingReadActionImpl$Submission.(NonBlockingReadActionImpl.java:272)
at com.intellij.openapi.application.impl.NonBlockingReadActionImpl.submit(NonBlockingReadActionImpl.java:227)
at com.redhat.devtools.intellij.lsp4ij.operations.diagnostics.LSPDiagnosticHandler.accept(LSPDiagnosticHandler.java:52)
at com.redhat.devtools.intellij.lsp4ij.operations.diagnostics.LSPDiagnosticHandler.accept(LSPDiagnosticHandler.java:38)
at com.redhat.devtools.intellij.lsp4ij.client.LanguageClientImpl.publishDiagnostics(LanguageClientImpl.java:68)
at jdk.internal.reflect.GeneratedMethodAccessor291.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.eclipse.lsp4j.jsonrpc.services.GenericEndpoint.lambda$null$0(GenericEndpoint.java:65)
at org.eclipse.lsp4j.jsonrpc.services.GenericEndpoint.notify(GenericEndpoint.java:152)
at org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.handleNotification(RemoteEndpoint.java:220)
at org.eclipse.lsp4j.jsonrpc.RemoteEndpoint.consume(RemoteEndpoint.java:187)
at com.redhat.devtools.intellij.lsp4ij.LanguageServerWrapper.lambda$start$1(LanguageServerWrapper.java:334)
at java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1804)
at java.base/java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1796)
at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:373)
at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1182)
at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1655)
at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1622)
at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:165)

[angelozerr]

We use now non blocking read action to improve performance. Do you feel better performance?

@mfortunat we are indeed aware about this problem and we will try to fix it but it should not block the features of IJ Quarkus.

This error should come when there are too many validation for instance while IJ is indexing. Jav avalidation requires the PsiFile indexed and as it is not indexed it waits and and we have two meany read action.

Thanks for reporting this issue. We will work on it.

[fbricon]

can you describe how it happens? no user activity during startup, or are you trying to do things during startup?
How big is your project (Nb files / Nb dependencies)

[angelozerr]

@mfortunat we have now a LSP console which track any messages (when validation should occur,completion etc).

Could you please activate trace as verbose:

And perhaps do the same thing for Qute language Server.

After that you shoud see LSP request/responses

When your problem occurs, could you share please your traces to see which services is too many called (I suspect it is the validation publish diagnostics)

Thanks!

[angelozerr]

After sen your trace::

t com.redhat.devtools.intellij.lsp4ij.operations.diagnostics.LSPDiagnosticHandler.accept(LSPDiagnosticHandler.java:52)
at com.redhat.devtools.intellij.lsp4ij.operations.diagnostics.LSPDiagnosticHandler.accept(LSPDiagnosticHandler.java:38)
at com.redhat.devtools.intellij.lsp4ij.client.LanguageClientImpl.publishDiagnostics(LanguageClientImpl.java:68)

It is the validation.

[mfortunat]

Hi @angelozerr, I enabled the verbose level tracing on both LSs.
I'll put here any additional info I get from the new configuration.

[mfortunat]

Hi @fbricon,
No special activities; just code editing.
It happens quite soon after IJ restart.
The project is a maven-based multi-module project with 5 modules.
Quarkus is '2.15.1.Final', Lombok, Kafka, Redis and Oracle.
Nothing particularly exotic

Hope this helps

[fbricon]

OK, so it's the initial indexing that's problematic. After that, quarkus tools should not get in your way

[mfortunat]

@angelozerr
I noticed something weird; after more than 5 minutes, the 2 processes are still "starting"

[angelozerr]

I noticed something weird; after more than 5 minutes, the 2 processes are still "starting"

Indeed that's very strange, I have never had this usecase, do you have the completion, validation features?

[angelozerr]

@mfortunat we have fixed the issue, now when a LSP request with the same parameter happens, it cancel the previous promise which should improve performance when you have a lot of validation for the same file and fix the "
Too many non-blocking read actions submitted at once".

[mfortunat]

Hi @angelozerr and @fbricon,
That's awesome!
Thank you guys for fixing so quickly this annoying issue.

[angelozerr]

The CI build is down for the momeent but when it will be available again you can download a zip of the IJ Quarkus for each commit and test the fix, see https://github.com/redhat-developer/intellij-quarkus#testing-the-ci-builds

[angelozerr]

The project is a maven-based multi-module project with 5 modules.

To be honnest with you ,I have never tried with multi module, but by reading quickly the code I think we could have some trouble (perhaps your starting which never stopped comes deom multi module).

We need to work on #891

@mfortunat is there any chance that you share your quarkus project to have the context than you?

[mfortunat]

Hi @angelozerr,

Sorry, this is not an OSS project so I cannot share anything about it.

[angelozerr]

Id not possible to share your multi module project by removing java classes of your project just to share yhe structure of your project?

[mfortunat]

If I remove the classes, you won't be able to build it.

What I can say, however, is:

• the main, external, module is just the container module where the main pom and dependencies are defined
• there is 1 common module shared across all other modules
• the other 4 modules are all @QuarkusApplication, with a controller (for monitoring & testing purposes), a Kafka consumer/producer or both, and one or more Services (@ApplicationScoped). There are also some DAO classes for interfacing with MongoDB.
  Each of the @QuarkusApplication is a separate microservice that runs in OpenShift as a Docker container.

The logic behind it is a set of ETL microservices working together and each one dealing with a part of a complex ETL pipeline.

[angelozerr]

I noticed something weird; after more than 5 minutes, the 2 processes are still "starting"

@mfortunat I can confirm you that you have this issue because you have multi-modules which is totally bugged. We plan to create the release 1.27 today,but it will not fix multi-modules problems. It is my priority an dI have started something #1129 which will be available in 1.28 (we will create it as soon as 2 very annoying bugs #1129 and #1097 (comment) will be fixed)