Spring Boot Tools Plugin Causes Java Searching to Hang in Large Projects (3300 Java Files) #1419
Assignees
Labels
Milestone
Comments
martinlippert
added
status: needs-investigation
for: vscode
|
Can you take a look into the log of the Java tooling as well and attach the output here? (both the java extension log and the java language server log You can open both via the command for The exception above looks like the Spring tooling waits too long for the Java tooling to respond when registering some listeners, so might be worth looking into what happens over there as well. If you import the project without the Spring Tools enabled, how long does it take for the project to be fully imported and the Java tooling is done with background jobs? |
Edited and attached the springboot tools log when the problem occurred Java Log Spring Log |
|
https://github.com/YunaiV/ruoyi-vue-pro.git |
|
@Skyxim thanks for the sample project!!! I wasn't able to reproduce the issue so far. By "Once in 3 times" you mean you execute "Reload Window" command in VSCode and every third time you see "Searching..." op from Java tooling gets stuck at startup, correct? I'd try and look for the reason for the shutdown on the Java LS side... All of this requires investigation... |
use |
|
I tried it today on Github Codespace and found that it does not get stuck at When I have time I will install a Debian VM in PVE and try this problem again. |
|
This problem seems to only occur under Debian. I also encountered it when I installed a virtual machine with Debian 12. I tried to install almalinux LXC in my PVE but did not encounter this problem. You may need to switch the development environment or use container development to solve it. |
|
I deleted |
|
Thanks a lot @Skyxim for the update on this and glad to hear that it looks like the problem is solved for the moment. Since there is nothing we can further investigate here, let's close the issue. If you come across this issue again, please comment and we can re-open anytime. |
|
Unfortunately, this problem still exists. Environment
What HappendWhen I open the project, the build always gets stuck at: I tried running Java: Clean Java Language Server Workspace and mvn clean, and even reinstalled the plugin, but none of it worked. logs when disable
|
|
@CloudSen Thanks for updating this issue with all the details, much appreciated. I have a few questions:
|
Thank you for your reply! Below are my answers to your questions:
With my project, it should get stuck at:
Hope the above info helps! |
|
Thanks @CloudSen for the additional details. Unfortunately I am having difficulties building your sample project even outside of VSCode, running |
Sry, I forgot to check the project's usability earlier. Now I've cleaned up the useless code and Maven dependencies. Here are the steps to build the project:
|
|
Thanks @CloudSen for the additional details and the cleanup work, much appreciated. I can successfully build and import the project now, and I can reproduce the issue. The Java indexing is stuck around 78%... 👍 For the technical analysis: and several other threads trying to use the index at the same time, many looking like this: I am not exactly sure why those calls cause the index to get stuck, but this is the piece where we need to investigate this in more detail, I think. It also looks to me like disabling the |
|
For the deeper investigation into the underlying issue, I filed microsoft/vscode-spring-boot-dashboard#352 for the dashboard project. |
|
Thank you for taking the time to investigate this issue. Yes, after
disabling the Spring Boot Dashboard, I was also able to build successfully.
Previously, I mentioned that I had disabled Spring Boot Tools, not
realizing that it would also disable the Spring Boot Dashboard plugin. So,
this isn't an issue with Spring Boot Tools, right? Things have gotten a bit
tricky.
Harder,Better,Faster,Stronger.
Martin Lippert ***@***.***>于2025年1月27日 周一18:26写道：
… Thanks @CloudSen <https://github.com/CloudSen> for the additional details
and the cleanup work, much appreciated. I can successfully build and import
the project now, and I can reproduce the issue. The Java indexing is stuck
around 78%... 👍
For the technical analysis:
The underlying thread dump of the Java language server show something like
this
"Java indexing" #36 [59907] daemon prio=5 os_prio=31 cpu=8958.72ms elapsed=107.93s tid=0x0000000110250200 nid=59907 waiting on condition [0x000000017351d000]
java.lang.Thread.State: WAITING (parking)
at ***@***.***/Native Method)
- parking to wait for <0x00000007eb08d498> (a java.util.concurrent.ForkJoinTask$AdaptedCallable)
at ***@***.***/Unknown Source)
at ***@***.***/Unknown Source)
at ***@***.***/Unknown Source)
at org.eclipse.jdt.internal.core.search.PatternSearchJob.performParallelSearch(PatternSearchJob.java:154)
at org.eclipse.jdt.internal.core.search.PatternSearchJob.execute(PatternSearchJob.java:115)
at org.eclipse.jdt.internal.core.search.processing.JobManager.performConcurrentJob(JobManager.java:286)
at org.eclipse.jdt.internal.core.search.BasicSearchEngine.searchAllSecondaryTypeNames(BasicSearchEngine.java:1727)
at org.eclipse.jdt.internal.core.JavaModelManager.secondaryTypesSearching(JavaModelManager.java:5067)
at org.eclipse.jdt.internal.core.JavaModelManager.secondaryTypes(JavaModelManager.java:4922)
at org.eclipse.jdt.internal.core.search.matching.ClasspathSourceDirectory.directoryTable(ClasspathSourceDirectory.java:79)
at org.eclipse.jdt.internal.core.search.matching.ClasspathSourceDirectory.findClass(ClasspathSourceDirectory.java:117)
at org.eclipse.jdt.internal.core.search.matching.ClasspathSourceDirectory.findClass(ClasspathSourceDirectory.java:113)
at org.eclipse.jdt.internal.core.search.matching.JavaSearchNameEnvironment.findClass(JavaSearchNameEnvironment.java:375)
at org.eclipse.jdt.internal.core.search.matching.JavaSearchNameEnvironment.findType(JavaSearchNameEnvironment.java:460)
at org.eclipse.jdt.internal.compiler.env.IModuleAwareNameEnvironment.findType(IModuleAwareNameEnvironment.java:100)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createPlainPackage(LookupEnvironment.java:1177)
at org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.buildTypeBindings(CompilationUnitScope.java:145)
at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.buildTypeBindings(LookupEnvironment.java:524)
at org.eclipse.jdt.internal.core.search.indexing.SourceIndexer.resolveDocument(SourceIndexer.java:183)
at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.resolveDocument(JavaSearchParticipant.java:125)
at org.eclipse.jdt.internal.core.search.indexing.IndexManager.indexResolvedDocument(IndexManager.java:668)
at org.eclipse.jdt.internal.core.search.indexing.IndexManager$2.execute(IndexManager.java:1272)
at org.eclipse.jdt.internal.core.search.processing.JobManager.indexerLoop(JobManager.java:541)
at org.eclipse.jdt.internal.core.search.processing.JobManager$$Lambda/0x00000070012c4e80.run(Unknown Source)
at ***@***.***/Unknown Source)
at ***@***.***/Unknown Source)
and several other threads trying to use the index at the same time, many
looking like this:
"ForkJoinPool.commonPool-worker-1" #316 [86791] daemon prio=5 os_prio=31 cpu=83.38ms elapsed=104.33s tid=0x0000000107c9ec00 nid=86791 in Object.wait() [0x0000000175411000]
java.lang.Thread.State: TIMED_WAITING (on object monitor)
at ***@***.***/Native Method)
- waiting on <no object reference available>
at ***@***.***/Unknown Source)
at org.eclipse.jdt.internal.core.search.processing.JobManager.performConcurrentJob(JobManager.java:362)
- locked <0x00000007c0c00e58> (a org.eclipse.jdt.internal.core.search.indexing.IndexManager)
at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:260)
at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:620)
at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:677)
at com.microsoft.java.debug.plugin.internal.ResolveMainClassHandler.resolveMainClassUnderPaths(ResolveMainClassHandler.java:149)
at com.microsoft.java.debug.plugin.internal.ResolveMainClassHandler.resolveMainClassCore(ResolveMainClassHandler.java:94)
at com.microsoft.java.debug.plugin.internal.ResolveMainClassHandler.resolveMainClass(ResolveMainClassHandler.java:65)
at com.microsoft.java.debug.plugin.internal.JavaDebugDelegateCommandHandler.executeCommand(JavaDebugDelegateCommandHandler.java:65)
at org.eclipse.jdt.ls.core.internal.handlers.WorkspaceExecuteCommandHandler$1.run(WorkspaceExecuteCommandHandler.java:230)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:47)
at org.eclipse.jdt.ls.core.internal.handlers.WorkspaceExecuteCommandHandler.executeCommand(WorkspaceExecuteCommandHandler.java:220)
at org.eclipse.jdt.ls.core.internal.handlers.JDTLanguageServer.lambda$4(JDTLanguageServer.java:610)
at org.eclipse.jdt.ls.core.internal.handlers.JDTLanguageServer$$Lambda/0x0000007001668418.apply(Unknown Source)
at org.eclipse.jdt.ls.core.internal.BaseJDTLanguageServer.lambda$0(BaseJDTLanguageServer.java:87)
at org.eclipse.jdt.ls.core.internal.BaseJDTLanguageServer$$Lambda/0x0000007001668650.apply(Unknown Source)
at ***@***.***/Unknown Source)
at ***@***.***/Unknown Source)
at ***@***.***/Unknown Source)
at ***@***.***/Unknown Source)
at ***@***.***/Unknown Source)
at ***@***.***/Unknown Source)
at ***@***.***/Unknown Source)
I am not exactly sure why those calls cause the index to get stuck, but
this is the piece where we need to investigate this in more detail, I think.
It also looks to me like disabling the Spring Boot Dashboard extension
works around this issue. At least that made this work for me and I only
lost the Spring Boot Dashboard functionality, not everything from the
Spring Tools. Can you verify that this works for you, too, @CloudSen
<https://github.com/CloudSen> ?
—
Reply to this email directly, view it on GitHub
<#1419 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGDW3TNQJ6H55VEV5WCIHQT2MYCTRAVCNFSM6AAAAABSW64KSOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMJVGM3DKOJXGE>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I will continue to follow up on this issue. Thank you very much ~
Harder,Better,Faster,Stronger.
Martin Lippert ***@***.***>于2025年1月27日 周一18:33写道：
… For the deeper investigation into the underlying issue, I filed
microsoft/vscode-spring-boot-dashboard#352
<microsoft/vscode-spring-boot-dashboard#352>
for the dashboard project.
—
Reply to this email directly, view it on GitHub
<#1419 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGDW3TNRK4SLQOGJXM2RF7D2MYDQDAVCNFSM6AAAAABSW64KSOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMJVGM4DEOBSGM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
That is good news!!! 👍
Yeah, no worries, this is totally not obvious from the outside... 😂 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
When loading a Spring Boot project containing approximately 3300 Java files, the Spring Boot Tools plugin (v1.58.0) causes the Java Searching phase of the Java Extension Pack to be stuck for a prolonged period, and the project fails to load. However, disabling the Spring Boot Tools plugin ensures that the Java Searching phase completes successfully.
Additionally, the issue persists even when using the pre-release version of Spring Boot Tools.
While the project is stuck, an exception is observed in the Spring Boot Tools logs, which seems to be related to the issue.
To Reproduce
• Spring Boot Tools (v1.58.0 or pre-release).
• Java Extension Pack (including Language Support for Java(TM) by Red Hat v1.37.0).
log
Sample
The text was updated successfully, but these errors were encountered: