LemMinX loading local artifacts doesn't seem to finish and makes whole of Eclipse a bitlaggy #517
Comments
Interrupt doesn't interrupt the job, see issue eclipse/lsp4e#742
Have you this problem with another local repo? |
|
I'm only using one maven local repo folder so far, lets see what happens when I try a fresh one. |
|
It looks like that somehow did the trick. I Just opened the pom again and this time the scan showed up for some seconds and then disappeared. But is this just a matter of size? The original had about 57k files with ~15 gb. The new one is just at ~2 gb sofar. |
It is to avoid polluating your real local repository when you are typing, see #213 (comment) |
|
Ah I see. Seems fine now. Do you have an idea how I could track down what in the repo caused the problem? Otherwise I have to keep a copy of the old one, because some artifacts can't be retrieved automatically., e.g. eclipse factory path entries. |
no sorry -( If you can investigate which artifactic provide this issue, it should be really nice. Thanks! |
|
Sorry for reviving this thread ... The issue still persists and it makes Eclipse almost unusable now... The org.eclipse.lemminx.XMLServerLauncher process that gets started when a pom.xml is opened, uses 100% of one CPU, and it never stops. The fan on my laptop is spinning at max all the time. I did an strace -f -p {pid of XMLServerLauncher process}, and found that is is constantly scanning my home directory. Scanning means opening every single file with statx(...), then closing it. Doing so, it appears it blindly follows symlinks, regardless of where they point. If they point to directories, those directories get scanned as well. In the case where symlinks point out of my home directory (more precisely to "/"), that leads to a circular read loop. / Now XMLServerLauncher scans /home/user, finds /home/user/a_symlink_to_root and starts scanning /, until it finds /home/user again and in it /home/user/a_symlink_to_root, starts scanning / again, and so on and so forth in all eternity. The progress bar stays at LemMinX: (90%), with the text "Loading local artifacts from ""...: Scanning folder ".mypaint" (1915 / 2127)... If I close the pom, the XMLServerLauncher process eventually stops (after some minutes). The next time I open a pom again, it all starts over, againg hanging at 90%. The OS (Linux in this case) does eventually (after ~10 min) cancel the statx() calls with "Too many levels of symbolic links" errors, but that does not stop the XMLServerLauncher from continuing. It seems to just go up one level and continue from there, always running into the same dead end. Not sure how to implement this, but I think there needs to be a protection against circular reads. |
|
can you report the result of |
|
jstack 10646 Threads class SMR info: "Reference Handler" #9 [10658] daemon prio=10 os_prio=0 cpu=2.48ms elapsed=110.11s tid=0x00007f7b0421cc40 nid=10658 waiting on condition [0x00007f7aec231000] "Finalizer" #10 [10659] daemon prio=8 os_prio=0 cpu=0.45ms elapsed=110.11s tid=0x00007f7b0421de10 nid=10659 in Object.wait() [0x00007f7aec131000] "Signal Dispatcher" #11 [10660] daemon prio=9 os_prio=0 cpu=0.26ms elapsed=110.11s tid=0x00007f7b04228830 nid=10660 waiting on condition [0x0000000000000000] "Service Thread" #12 [10661] daemon prio=9 os_prio=0 cpu=6.27ms elapsed=110.11s tid=0x00007f7b04229da0 nid=10661 runnable [0x0000000000000000] "Monitor Deflation Thread" #13 [10662] daemon prio=9 os_prio=0 cpu=6.54ms elapsed=110.11s tid=0x00007f7b0422b340 nid=10662 runnable [0x0000000000000000] "C2 CompilerThread0" #14 [10663] daemon prio=9 os_prio=0 cpu=2009.49ms elapsed=110.11s tid=0x00007f7b04220420 nid=10663 waiting on condition [0x0000000000000000] "C1 CompilerThread0" #17 [10664] daemon prio=9 os_prio=0 cpu=1426.44ms elapsed=110.11s tid=0x00007f7b04221a90 nid=10664 waiting on condition [0x0000000000000000] "Notification Thread" #18 [10665] daemon prio=9 os_prio=0 cpu=0.15ms elapsed=110.08s tid=0x00007f7b042c5cf0 nid=10665 runnable [0x0000000000000000] "Common-Cleaner" #19 [10666] daemon prio=8 os_prio=0 cpu=2.38ms elapsed=110.07s tid=0x00007f7b042ca880 nid=10666 waiting on condition [0x00007f7add626000] "pool-4-thread-1" #25 [10673] prio=5 os_prio=0 cpu=10.06ms elapsed=109.65s tid=0x00007f7b045d4c50 nid=10673 waiting on condition [0x00007f7adceec000] "pool-5-thread-1" #26 [10676] prio=5 os_prio=0 cpu=406.77ms elapsed=109.46s tid=0x00007f7b0466b040 nid=10676 runnable [0x00007f7adcdec000] "DestroyJavaVM" #27 [10648] prio=5 os_prio=0 cpu=686.24ms elapsed=109.46s tid=0x00007f7b04029920 nid=10648 waiting on condition [0x0000000000000000] "pool-6-thread-1" #30 [10684] prio=5 os_prio=0 cpu=0.23ms elapsed=109.23s tid=0x00007f7a8805a830 nid=10684 waiting on condition [0x00007f7adcaea000] "ForkJoinPool.commonPool-worker-1" #31 [10685] daemon prio=5 os_prio=0 cpu=106082.10ms elapsed=109.22s tid=0x00007f7a88076830 nid=10685 runnable [0x00007f7adc9e4000] "ForkJoinPool.commonPool-worker-2" #32 [10686] daemon prio=5 os_prio=0 cpu=99.24ms elapsed=109.22s tid=0x00007f7a88086f40 nid=10686 waiting on condition [0x00007f7adc8ea000] "ForkJoinPool.commonPool-worker-3" #33 [10687] daemon prio=5 os_prio=0 cpu=7.35ms elapsed=109.21s tid=0x00007f7a88088950 nid=10687 waiting on condition [0x00007f7adc7ea000] "ForkJoinPool.commonPool-worker-4" #34 [10688] daemon prio=5 os_prio=0 cpu=1318.73ms elapsed=109.21s tid=0x00007f7a88089f70 nid=10688 waiting on condition [0x00007f7adc6ea000] "ForkJoinPool.commonPool-worker-5" #35 [10689] daemon prio=5 os_prio=0 cpu=4.39ms elapsed=109.21s tid=0x00007f7a8808b390 nid=10689 waiting on condition [0x00007f7adc5ea000] "ForkJoinPool.commonPool-worker-6" #37 [10691] daemon prio=5 os_prio=0 cpu=0.80ms elapsed=109.03s tid=0x00007f7a88169ce0 nid=10691 waiting on condition [0x00007f7adc3e9000] "ForkJoinPool.commonPool-worker-7" #38 [10692] daemon prio=5 os_prio=0 cpu=0.27ms elapsed=109.03s tid=0x00007f7a60000ff0 nid=10692 waiting on condition [0x00007f7adc2e9000] "Thread-0" #40 [10698] daemon prio=5 os_prio=0 cpu=0.40ms elapsed=107.99s tid=0x00007f7a645e0600 nid=10698 waiting on condition [0x00007f7a53ffe000] "HttpClient-1-SelectorManager" #41 [10699] daemon prio=5 os_prio=0 cpu=3.73ms elapsed=107.73s tid=0x00007f7a646a1260 nid=10699 runnable [0x00007f7a53efe000] "pool-7-thread-1" #42 [10700] prio=5 os_prio=0 cpu=7.91ms elapsed=107.70s tid=0x00007f7a646aace0 nid=10700 waiting on condition [0x00007f7a53dfe000] "Attach Listener" #45 [10748] daemon prio=9 os_prio=0 cpu=0.37ms elapsed=70.34s tid=0x00007f7ac0000ff0 nid=10748 waiting on condition [0x0000000000000000] "process reaper" #46 [10750] daemon prio=10 os_prio=0 cpu=2.65ms elapsed=69.64s tid=0x00007f7a8402f050 nid=10750 waiting on condition [0x00007f7add426000] "VM Thread" os_prio=0 cpu=148.44ms elapsed=110.13s tid=0x00007f7b0418f300 nid=10656 runnable "GC Thread#0" os_prio=0 cpu=212.77ms elapsed=110.16s tid=0x00007f7b040915d0 nid=10650 runnable "GC Thread#1" os_prio=0 cpu=206.49ms elapsed=109.77s tid=0x00007f7ac4007a70 nid=10669 runnable "GC Thread#2" os_prio=0 cpu=212.41ms elapsed=109.77s tid=0x00007f7ac4008550 nid=10670 runnable "GC Thread#3" os_prio=0 cpu=215.82ms elapsed=109.77s tid=0x00007f7ac4009030 nid=10671 runnable "GC Thread#4" os_prio=0 cpu=208.03ms elapsed=109.77s tid=0x00007f7ac4009b10 nid=10672 runnable "GC Thread#5" os_prio=0 cpu=207.48ms elapsed=109.36s tid=0x00007f7ac40120d0 nid=10677 runnable "GC Thread#6" os_prio=0 cpu=199.47ms elapsed=109.36s tid=0x00007f7ac4011640 nid=10678 runnable "GC Thread#7" os_prio=0 cpu=197.33ms elapsed=109.17s tid=0x00007f7ac400b6f0 nid=10690 runnable "G1 Main Marker" os_prio=0 cpu=13.75ms elapsed=110.16s tid=0x00007f7b040a2370 nid=10651 runnable "G1 Conc#0" os_prio=0 cpu=1882.03ms elapsed=110.16s tid=0x00007f7b040a3310 nid=10652 runnable "G1 Conc#1" os_prio=0 cpu=1891.23ms elapsed=108.93s tid=0x00007f7ae0000d90 nid=10695 runnable "G1 Refine#0" os_prio=0 cpu=56.26ms elapsed=110.16s tid=0x00007f7b0412e0b0 nid=10653 runnable "G1 Service" os_prio=0 cpu=14.75ms elapsed=110.16s tid=0x00007f7b0412f060 nid=10654 runnable "VM Periodic Task Thread" os_prio=0 cpu=35.44ms elapsed=110.16s tid=0x00007f7b0413f000 nid=10655 waiting on condition JNI global refs: 18, weak refs: 0 |
|
The list of "at org.eclipse.lemminx.extensions.maven.searcher.LocalRepositorySearcher$Cache.updateArtifacts(LocalRepositorySearcher.java:241)" lines under "ForkJoinPool.commonPool-worker-1" #31 [10685] |
|
Definitely. But there's also the question why lemminx would look for artifacts in my entire home directory in the first place. |
|
lemminx-maven indexes your local repository so it can provide content-assist when editing |
|
Yes, agreed. But what is the definition of "local repository"? I'd expect it to index the repositories under ~/.m2, but not everything in my home directory. Can the scope of "local repository" be configured anywhere in Eclipse? |
Hi there,
since I updated Eclipse to 23-09 this task seems to run all the time and never getting through.
In Progress it states LemMinX - loading local artifacts from , 170k of 200k...
Which in turn is strange as well, the folder doesn't even have 200k files :)
It started shortly after I first opened a pom.xml. When I interrupt it from progress view, it comes up again in the next pom.
This constantly consumes ~10% of CPU. Its Running since 5 hours now and the numbers don't move.
Is there anything I can check or some way to speed it up? :)
Best
Martin
The text was updated successfully, but these errors were encountered: