Closed kdvolder closed 5 years ago
(comment in Pivotal Tracker added by Kris De Volder:)
From the stack traces, there are bunch of calls to the namespaces resolver. But the one that is seemingly hanging the ui thread is coming from m2e when doing something with the pom.xml. I beleave the pom.xml should be treated as a special case and skipped since we don't want to resolve spring namespaces definitions from the classpath for pom anyway.
So, I pushed a small change that checks if the current file is 'pom.xml' and just skips it.
I was about to report on this issue but wasn't sure. But now as you mention it, I can confirm a delay when opening a pom.xml with the "Maven POM Editor" which got introduced "recently".
@mweirauch That sounds like the same problem yes. If you can try out a nightly build with the attempt at fixing this, and let us know if it solves the issue for you, that would be greatly appreciated.
You can download it from here: http://dist.springsource.com/snapshot/STS4/nightly-distributions.html
@kdvolder I just tried with `Spring Tool Suite 4 / Version: 4.3.1.CI-B1921 / Build Id: 201907120604" and my "work" workspace, and it takes up to 6 seconds to open a pom.xml with the "Maven POM Editor".
Setup: Fedora30, i7-6820HQ CPU @ 2.70GHz × 8; 32GB RAM
Perhaps related (please let me know if this derails from the main topic):
jps | grep BootLanguagServerBootApp | wc -l
53
All from afformentioned STS4-nightly distribution. Might be due to the many Spring Boot projects in the workspace. Processes were gone when closing STS4.
The delay even feels longer then on my main Eclipse+STS4 installation. (4.12-nightly some days old; have trouble updating to current setup though).
An error occurred while collecting items to be installed
session context was:(profile=xxx, phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=, action=).
Artifact not found: https://dist.springsource.com/snapshot/TOOLS/sts4/nightly/e4.12/features/org.springframework.boot.ide.main.feature_4.3.1.201907111441-CI-B1919.jar.
https://dist.springsource.com/snapshot/TOOLS/sts4/nightly/e4.12/features/org.springframework.boot.ide.main.feature_4.3.1.201907111441-CI-B1919.jar
Artifact not found: https://dist.springsource.com/snapshot/TOOLS/sts4/nightly/e4.12/binary/org.springframework.boot.ide.main.feature_root_4.3.1.201907111441-CI-B1919.
https://dist.springsource.com/snapshot/TOOLS/sts4/nightly/e4.12/binary/org.springframework.boot.ide.main.feature_root_4.3.1.201907111441-CI-B1919
Lets try to find the reason step by step here.
The delay even feels longer then on my main Eclipse+STS4 installation. (4.12-nightly some days old; have trouble updating to current setup though).
The fundamental question here is whether this is related to the Spring Boot language server starting up in the background and occupying the CPU or blocking the UI somehow or if the XML namespace support is in charge here and responsible for the slowness.
To identify this, you can go to the Preferences -> Language Servers
and disable the Spring Boot Language Server
for the Spring XML Config File
content-type. Then restart your IDE and try to open a pom file again. If the behavior different? Or the same?
If it is different (assuming better), then opening a Java file next and observe what happens. If there again any slowness or freeze happening?
An error occurred while collecting items to be installed session context was:(profile=xxx, phase=org.eclipse.equinox.internal.p2.engine.phases.Collect, operand=, action=). Artifact not found: https://dist.springsource.com/snapshot/TOOLS/sts4/nightly/e4.12/features/org.springframework.boot.ide.main.feature_4.3.1.201907111441-CI-B1919.jar. https://dist.springsource.com/snapshot/TOOLS/sts4/nightly/e4.12/features/org.springframework.boot.ide.main.feature_4.3.1.201907111441-CI-B1919.jar Artifact not found: https://dist.springsource.com/snapshot/TOOLS/sts4/nightly/e4.12/binary/org.springframework.boot.ide.main.feature_root_4.3.1.201907111441-CI-B1919. https://dist.springsource.com/snapshot/TOOLS/sts4/nightly/e4.12/binary/org.springframework.boot.ide.main.feature_root_4.3.1.201907111441-CI-B1919
This happened probably due to the update repository being updated while you where trying to access it, causing stale repository cache data in your repo. To solve this, you can go to the Preferences -> Install/Update -> Available Update Sites
, select the STS4 nightly one that you seem to use, and press Reload
. In some cases, that is enough. If not, delete the update site from the preferences, restart the IDE, and add it back. That wipes out the stale cache data as a last resort.
@mweirauch @wilkinsona It looks like Nieraj can reproduce this and it seems indeed related to the language server being enabled for Spring XML config files. We need to investigate this in more depth, but I wanted to let you know that in case you don't need any Spring specific content-assist support in XML files, you can disable the language server for XML files in the preferences and that will speed up opening pom.xml files, too.
We will work on a solution for that. Will not make it into the 4.3.1 release (going out today), but soon after.
(comment in Pivotal Tracker added by Martin Lippert:)
still performance issues, see additional comments on GitHub
I made some small adjustments to content-type defintions, which relates to language server being triggered for various xml files when it shouldn't due to a bug in lsp4e.
See: https://github.com/spring-projects/sts4/issues/320
This may also be related to the performance issues when opening pom.xml
since I saw that basically any xml file, including pom.xml
was treated as a spring config file and caused starting language server process.
@mweirauch
jps | grep BootLanguagServerBootApp | wc -l
53
53 language servers?! That seems very odd and highly suspicious. Should only be one server at most per active Eclipse instance. Maybe it is not related to the performance problem you are having, but at the least its really not supposed to have that many servers running and indeed, that many processes would put a strain on your entire machine, the memory consumtion alone should probably grind any machine to a halt.
It is interesting to note that the processes all went away when you closed STS, so that kind of implies that all these processed did actually belong to that same STS instance and were not just accumulated rogues left over from something that crashed.
When I try and keep an eye on the number of BootLanguagServerBootApp
processes it seems to be as expected, just one per instance of running STS.
@kdvolder The 53 language server processes where observed with Spring Tool Suite 4 (2019-06) / Version: 4.3.1.CI-B1921 / Build Id: 201907120604
.
I just tried with Spring Tool Suite 4 (2019-06) / Version: 4.3.2.CI-B1925 / Build Id: 201907161853
and there is only one BootLanguagServerbootApp
with the same workspace. So might have been a regression or bad luck.
Regarding the inital topic, I enabled "Spring XML Config files support", restarted afformentioned STS4 nightly and there seems to be no noticeable delay anymore for me. (only the first open of a pom.xml had a small 1s delay; subsequent opens are "fast")
@mweirauch Thanks for trying again. I am still suspicious of the 53 servers situation. But until you see it happening again I think there's not much we can do now, and possibly recent changes have actually fixed the issue also.
So I will close this ticket for now. But please don't hesitate to post more details here or raise a new issue, if your experience more issues.
(comment in Pivotal Tracker added by Martin Lippert:)
Looks like this is solved, but changes might have caused this to break: #167561911
We also observed a UI freeze of 66 seconds due to this bug. Using the nightly build from https://dist.springsource.com/snapshot/STS/nightly-distributions.html solved that for us.
Thanks for the fix @kdvolder
@vogella Great to hear that this fixed the issue on your end, too.
@wilkinsona Reported that he is seeing long and annoying ui freezes in STS 4. After turning on UI responsiveness monitoring a few stacktraces were collected. At first sight I'd say that the xmlnamespaces resolution mechanism is causing this somehow.
I'm attaching the stacktraces below. Also there are some instructions on setting up a workspace similar to Andy's that may help us reproduce this problem here: https://github.com/spring-projects/spring-boot/blob/master/CONTRIBUTING.adoc#importing-into-eclipse