Community
Participate
Working Groups
This problem was found when I tried to look into bug 191280. To mimic Martin's scenario, I wrote a program to duplicate about 4000 folders in one of my directory in a Linux machine (directory named "dummy"). I expanded dummy in a SSH connection, and got the results almost right away. The I refreshed this directory, and its job just kept on running. It eventually finished, but took at least 20 mins. The whole IDE hang (even it seems was running in a separated job). -----------Enter bugs above this line----------- TM RC2 Testing installation : eclipse-platform-3.3M7 (I20070503-1400) RSE install : RSE-SDK-2.0RC2.zip java.runtime : Sun 1.5.0_06-b05 os.name: : Windows XP 5.1, Service Pack 2 ------------------------------------------------ systemtype : Linux - SSH
Ouch. Refresh should not take longer than initial population.
Kevin tried it in the lastest dev driver, and could not reproduce it. So I gave it a try again today, using RC2 driver (the driver used for testing before), and could not reproduce it either. So I will close it for now.
Kushal and I tried this and can't reproduce it using the latest dev driver with eclipse 3.3RC3. Sometimes it took a little longer to refresh the directory and others it looked to take the same amount of time.
It seems I still got this problem occationally. I downloaded the 0713 2.0.1 driver, and tried this scenario. The first time I refresh a very large folder (with 4000 subfolders), I waited for 3 mins. The UI was frozen. Then I need to step away from my computer. When I came back around 15 mins, the folder had been expanded correctly. I refreshed it again, and it took more than 11 mins, and the UI is totally frozen. I have to kill the workbench. Then I started it again, and I did not have this problem any more (I've tried at least 7-8 time, and no problem at all).
I tried the scenario and found two potential problems, which I created separate bugs to track: 1. Bug 196662 - During Refresh, a getFile() query is made on the dispatch thread. Since SSH only has a single dirChannel, the backgroundThread can block the UI thread through the mutex being used, leading all of Eclipse to freeze. I marked that bug as Major / P2. 2. Bug 196664 - When refreshing multiple times in a row, more and more getFile() queries are scheduled on parents of the given directory. Issue 2 could be the reason why it sometimes works and sometimes not, although I'd personally think that the long delay comes from problems with the file system on the remote that we cannot get fixed - so our only chance is to make sure all remote queries are done in the background. Reopening this to reverify when the two depenent bugs are addressed.
Assigning Xuan to reverify once the dependent bugs are addressed, since she's got the 4000 file setup.
I sync-ed up with the cvs, and tried this scenario again. I got this problem again, and now, already 20 min pass, I still got the hanging. I will attach the stack dump for it. I've taken around 4 stack dumps, and they are similar. I will attach just one of them.
Just as I finished typing last comment, the operation completed. Now my workspace space back to normal. It took about 5:04 - 4:39 = 25 mins.
Created attachment 74626 [details] Stackdump when the workspace hangs
Did you really test this with SSH? - The stackdump seems to indicate dstore is running, but no SSH. From the stackdump, it looks to me like the problem is in the main thread at SystemView.recursiveFindAllRemoteItemReferences() -- which would mean that the remote is not necessarily involved and the performance issue could be found with a profiler. Did you ever try refreshing 4000 directories on Local?
Did you look at the Task manager / cpu utilization while this was running? Was your cpu mostly idle (indicating a problem with the remote) or at 100% (indicating a problem with the refresh / recursiveFind)?
You are right. I have two connections (one dstore and one ssh), and I accidently picked the dstore one and try. I tried the ssh one twice, and it worked fine. But I tried the dstore one, still got the same problem. My workbench is still hanging, and it seems hang in the same spot. My javaw.exe take about 30-40 % of my CPU.
Does this mean that the issue for SSH is no longer there? Then we should either change the summary to reference dstore, or mark this bug fixed and create a new one for the dstore issue.
I gave it a try again, and SSH is fine. But I still got the hang for dstore one. And the stack dump shows the same place. I will close this one and open a different bug to track the DStore problem.
Xuan: we're tracking dstore now with bug 198143, is it ok to close this ssh one?
I cannot reproduce it any more.
close it.
