-
Notifications
You must be signed in to change notification settings - Fork 206
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UI freezes caused by xmlnamespace support? #318
Comments
(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):
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.
|
Lets try to find the reason step by step here.
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 If it is different (assuming better), then opening a Java file next and observe what happens. If there again any slowness or freeze happening?
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 |
@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: #320 This may also be related to the performance issues when opening
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 |
@kdvolder The 53 language server processes where observed with I just tried with 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
The text was updated successfully, but these errors were encountered: