fix: Too many non-blocking read actions submitted at once in LSPDiagnosticHandler #1101
Conversation
angelozerr
force-pushed
the
diagnostic-non-blocking
branch
from
0301c16
to
7b9031d
Compare
|
I created the PR but as I cannot reproduce it (hope @mfortunat could give us more info) , I cannot confirm that it fixes the issue. I will try to emulate this usecase. |
angelozerr
force-pushed
the
diagnostic-non-blocking
branch
6 times, most recently
from
02be812
to
5bdba9b
Compare
|
The PR is ready. To test, I retriggered the project index, and I type a lot of characters to handle diagnostics and I had no error. I debug the IJ promise in the onError and I receive CANCELED exception which cancel the previous diagnostics. I tried do do the same thing for all operations. |
LSPDiagnosticHandler Fixes redhat-developer#1089 Signed-off-by: azerr <[email protected]>
angelozerr
force-pushed
the
diagnostic-non-blocking
branch
from
5bdba9b
to
882e475
Compare
|
Kudos, SonarCloud Quality Gate passed!
|
| private CancellablePromise<ResultOrError<R>> nonBlockingReadActionPromise; | ||
|
|
||
| public LSPCompletableFuture(Function<ProgressIndicator, R> code, String progressTitle, IndexAwareLanguageClient languageClient) { | ||
| public LSPCompletableFuture(Function<ProgressIndicator, R> code, String progressTitle, IndexAwareLanguageClient languageClient, Object coalesceBy) { |
There was a problem hiding this comment.
why Object and not a CoalesceByKey?
There was a problem hiding this comment.
because perhaps some services don't need that and have an object which defines an unique hashcode
|
I hammered the LS during reindexation, they didn't skip a beat. Impressive work @angelozerr! |
LSPDiagnosticHandler](fix: Too many non-blocking read actions submitted at once in LSPDiagnosticHandler
Fixes #1089