JDTLS startup takes a long time due to timeout of "refreshing workspace" job

[RKBK]

I'm running JDTLS via emacs using lsp-java. The java project is a Plugin-development environment project consisting of several dozen plugins. I'm running JDTLS with PDE extensions, as described here #2043 (comment)

I'm also using the following vmargs for jdtls (extracted from the list in emacs, the arguments get sent correctly by lsp-java):

"-XX:+UseParallelGC"
                                  "-XX:GCTimeRatio=4"
                                  "-XX:AdaptiveSizePolicyWeight=90"
                                  "-Dsun.zip.disableMemoryMapping=true"
                                  "-Xmx16G"
                                  "-Xms1G"
                                  "-noverify"
                                  "-XX:+UseStringDeduplication"

In addition, I'm using the lsp-java setting "lsp-java-autobuild-enabled", which is set to nil, to disable automatic building.

When starting JDTLS, I get a few log messages, then nothing for five minutes, at which point I get the message:
"Apr 27, 2022, 2:32:25 PM Timeout while waiting for completion of job: Refreshing workspace(11)"
The startup of JDTLS then continues.

It would be nice to reduce the startup time of JDTLS, so any help with what might cause that timeout is welcome.

I'm attaching the lsp-java log of the startup (it contains both messages from JDTLS and from lsp-java, but it's probably easy to see which is which).
jdtls_log.txt

[snjeza]

@RKBK you may want to take a look at #1960

[RKBK]

Thanks, @snjeza ! I take it I need to wait for #1960 to be merged, and then download the new version of JDT.LS?

[snjeza]

The java project is a Plugin-development environment project consisting of several dozen plugins

@RKBK could you attach this project?

[RKBK]

The java project is a Plugin-development environment project consisting of several dozen plugins

@RKBK could you attach this project?

Unfortunately not.

[snjeza]

what might cause that timeout is welcome.

I suppose the timeout is caused by downloading your target platform
Could you try it in VS Code using https://github.com/snjeza/vscode-test/raw/master/java-1.5.8.vsix and

"java.jdt.ls.vmargs": "-Djava.ls.doNotSetDefaultJVM=true -XX:+UseParallelGC -XX:GCTimeRatio=4 -XX:AdaptiveSizePolicyWeight=90 -Dsun.zip.disableMemoryMapping=true -Xmx16G -Xms1G ",

[RKBK]

My first quick attempt at installing it in vscode failed, or rather, I installed it but didn't get vscode to recognize my project and start the server.

Is there a way for you to provide that file in the same format as what is here:

https://download.eclipse.org/jdtls/milestones/1.5.0/jdt-language-server-1.5.0-202110191539.tar.gz

This file is what lsp-java retrieves to install the language server. I believe I could easily test the changed server if I can just replace that url with the location of a tar.gz with the updated server.

If this is difficult, I'll see if I can try vscode again.

[RKBK]

I'll try using the latest milestone version of the server (1.9.0), too, to see if that makes any difference. That should be easy to try.

I tried it in 1.9.0 and I can at least conclude that it behaves the same way as 1.5.0.

[snjeza]

My first quick attempt at installing it in vscode failed, or rather, I installed it but didn't get vscode to recognize my project and start the server.
I'll try using the latest milestone version of the server (1.9.0), too, to see if that makes any difference. That should be easy to try.
I tried it in 1.9.0 and I can at least conclude that it behaves the same way as 1.5.0.

@RKBK you should install https://marketplace.visualstudio.com/items?itemName=yaozheng.vscode-pde
See Auto import Eclipse PDE projects

Is there a way for you to provide that file in the same format as what is here:

https://github.com/snjeza/vscode-test/raw/master/jdt-language-server-1.11.0-202204291616.tar.gz includes #1961

[RKBK]

I'm currently starting my project with the new server.

By the way, is it expected that every time you change the jdtls version, by installing a new one, you have to reinitialize the workspace and import everything again? That's at least the behavior I'm observing. Changing to 1.9.0 caused the server to import all the plugins again. Installing your version 1.11.0 from github causes the same thing to happen right now.

This is the most recent server output:

May 1, 2022, 1:50:19 PM LoadingGradleVersionJob finished 277ms
Init...[Starting]
0% Starting Java Language Server[Starting]
May 1, 2022, 1:50:19 PM Creating the Java project jdt.ls-java-project
May 1, 2022, 1:50:19 PM >> initialized
May 1, 2022, 1:50:19 PM Finished creating the Java project jdt.ls-java-project
31% Starting Java Language Server - Refreshing '/jdt.ls-java-project'.[Starting]

I guess it could be either due to jdtls itself, or due to how lsp-java initializes it.

Reinitializing the workspace like this takes about 20 minutes, so it's a bit of a pain.

However, after going through this process, letting the 1.11.0 LS completely initialize, turning it off, and then turning it on again, I can conclude that the the suggested fix made no difference.

Here's the relevant output, showing that the five minute timeout remains:

May 1, 2022, 2:57:15 PM Started org.eclipse.m2e.core 1ms
May 1, 2022, 3:02:15 PM Timeout while waiting for completion of job: Refreshing workspace(12)

Here are the flags I used for the server:

("-Djava.ls.doNotSetDefaultJVM=true" "-XX:+UseParallelGC" "-XX:GCTimeRatio=4" "-XX:AdaptiveSizePolicyWeight=90" "-Dsun.zip.disableMemoryMapping=true" "-Xmx16G" "-Xms1G" "-noverify" "-XX:+UseStringDeduplication" "-Djava.format.settings.url=/mnt/c/code/our_formatter.xml")

[snjeza]

By the way, is it expected that every time you change the jdtls version, by installing a new one, you have to reinitialize the workspace and import everything again

No, it isn't. It happens only if you change your workspace or target platform.

Here's the relevant output, showing that the five minute timeout remains:
May 1, 2022, 2:57:15 PM Started org.eclipse.m2e.core 1ms
May 1, 2022, 3:02:15 PM Timeout while waiting for completion of job: Refreshing workspace(12)

Could you attach your target platform?
Could you check Java LS ?
Does it happen in VS Code?

[RKBK]

Unfortunately, I can't share any of the code. I realize it's much more difficult helping me find the issue, that way. Is there anything specific that I could look for in the target platform definition, that would be useful information?

I might not understand your second question. The result above was with the JDTLS downloaded from https://github.com/snjeza/vscode-test/raw/master/jdt-language-server-1.11.0-202204291616.tar.gz .

Is there any way to get more output about the "refresh" operation?

[snjeza]

Unfortunately, I can't share any of the code. I realize it's much more difficult helping me find the issue, that way. Is there anything specific that I could look for in the target platform definition, that would be useful information?

How many plugins does your target platform contain? - <YOUR_WORKSPACE>/redhat.java/jdt_ws/.metadata/.plugins/org.eclipse.pde.core/.bundle_pool/plugins/
How many plugins does your project contain?

I might not understand your second question

Could you try to import Eclipse JDT Language Server instead of your project.

Is there any way to get more output about the "refresh" operation?

It is a m2e job - https://github.com/eclipse-m2e/m2e-core/blob/master/org.eclipse.m2e.core/src/org/eclipse/m2e/core/internal/project/registry/ProjectRegistryRefreshJob.java
Your project is probably pretty big.

Could you try

• https://github.com/snjeza/vscode-test/raw/master/java-1.5.9.vsix
• https://github.com/snjeza/vscode-test/raw/master/vscode-pde-0.6.1.vsix
• https://github.com/snjeza/vscode-test/raw/master/jdt-language-server-1.11.0-202205021901.tar.gz

[RKBK]

The total number of <plugin tags in our .target file is 361, including both our own plugins and plugins from elsewhere used in the program. There are about 190 plugins for which I have the source code checked out.

I'll try to find time to try the three new files you suggested, and to try to import the JDTLS project with my local configuration. When importing the Eclipse JDT Language server, is it acceptable to just clone the repository and initialize the project from its root folder with JDT.LS?

[snjeza]

... is it acceptable to just clone the repository and initialize the project from its root folder with JDT.LS?

Yes, it is.

git clone [email protected]:eclipse/eclipse.jdt.ls.git
cd eclipse.jdt.ls
code .

You may want to take a look at javaConfig.json - Auto import Eclipse PDE projects

Java LS has 4 plugins, its target platform has 800+ plugins.

There are about 190 plugins for which I have the source code checked out.

Does your project have 190 plugins? Could you try to import them partially? Do you try to import them in Eclipse or VS Code?

[RKBK]

In the end, I figured out what the main problem here was. It was my fault, and not related to jdtls. The issue was that I was using windows subsystem for linux, and ran jdtls on the linux file system, but I stored my project files on the windows file system. Communication between these file systems is not recommended, because it's so slow.

I've now tried working on the same project, with emacs and jdtls, but with emacs and jdtls installed under msys on the windows filesystem. This is much faster. Starting the jdtls language server takes maybe half a minute or less. I'm closing this issue.