Community
Participate
Working Groups
Build Identifier: 20100617-1415 Environment ----------- Eclipse: Eclipse Helios for JEE Developers OS: Ubuntu 10.04 JDK: Sun JDK 1.6.0_20 When I open a JSP (any JSP) in Eclipse Helios the whole workbench will freeze for at least two minutes with a maximum CPU load on one of my CPUs. This happens on my machine as well as on the machines of some of my colleagues. Sometimes I even have to kill Eclipse since it will not respond anymore. Looking at Eclipse using "jvisualvm" there seems to be no memory problem, heap and PermGen memory is fine. I did a few thread dumps and it looks like there is a deadlock. Sometimes the main thread is locked sometimes a worker thread but always with the same stack trace (see "Worker-15" and thread main in attachment). I also tried to disable all Validators (including JSP) but to no avail. Reproducible: Always Steps to Reproduce: 1. Open a JSP in JSP editor
Created attachment 175783 [details] Thread-Dump of Eclipse with max CPU load Thread-Dump
In my workspace I had the same problem. After debugging i found the following: org.eclipse.jst.jsp.core.taglib.TaglibIndex#calculateCacheLimit(): "Calculate the maximum number of project descriptions to keep cached. Calculated as: MINIMUM_LIMIT_FOR_PROJECT_DESCRIPTIONS_CACHE + log(currentWorkspaceProjectCount)" Where MINIMUM_LIMIT_FOR_PROJECT_DESCRIPTIONS_CACHE is 3. So suppose you have a workspace with 10 projects, where your main one (that with the JSPs) depend on all others. Then the taglib index is recreating the project descriptions over and over again, as the cache holds only 3 + ln(10) = 5 elements. That results in heavy CPU load as creating a project description is time consuming. Solution for me was to change the method to: private int calculateCacheLimit() { return MINIMUM_LIMIT_FOR_PROJECT_DESCRIPTIONS_CACHE + ResourcesPlugin.getWorkspace().getRoot().getProjects().length; } You could also create ((e^projectCount) - projectCount) empty projects - but for our example of 10 projects that would mean to create ~22000 empty one.
Created attachment 176965 [details] Patch for the TaglibIndex cache size calculation I added a patch for the proposed quick fix. But I would suggest to revise the cache strategy in the TaglibIndex, as the cache is not resized when new projects are added, which will lead to the same CPU load during setup of a workspace from repository.
I was seeing the same thread dumps on my installation (I'll attach the stack trace of the main thread taken in an interval of about 20 seconds to the ticket) as I have to wait for about 5 minutes on openeing any JSP in our main dynamic web project. This was very annoing and I already started to edit JSPs in an alternative editor, but after things did not improve on loading Eclipse Helios SR1 today, I decided to debug Eclipse to see what is going on. Our project is build of multiple Maven modules - it has one main dynamic web project (creating a war) and several important Java projects (creating jars), which I have opened in my workspace. One project is a taglib project (creating a JAR), where the TLDs are under src\resources\META-INF. We have no taglib reference in the web.xml of the main dynamic web project and we also have many dynamic web projects using these taglibs and I have them loaded into the same workspace now and then. When opening a JSP I can see that the method org.eclipse.jst.jsp.core.internal.contentmodel.tld.TLDCMDocumentManager.getCMDocument will start loading the project descriptions over and over again in these method calls: Object cacheKey = getCacheKey(reference); ... long lastModified = getModificationStamp(reference); ... CMDocument document = loadTaglib(reference); ... entry.modificationStamp = getModificationStamp(reference); As mentioned previously in this bug report, this is because the cache limit for the project descriptions cache in the TaglibIndex is too small. 1st Suggestion: Perhaps there could be some logic added that the fProjectDescriptions cache is not plainly evicting the oldest records, but the ones which have the least success ratio when resolving taglibs. This way the projects being able to resolve taglibs will stay longer in memory. 2nd suggestion: Another possibility to improve things is a slight refactoring in org.eclipse.jst.jsp.core.taglib.ProjectDescription.resolve(String, String) Here we come into the following part: if (record == null && jspVersion >= 1.2) { Map buildPathReferences = new HashMap(); List projectsProcessed = new ArrayList(fClasspathProjects.size() + 1); projectsProcessed.add(fProject); addBuildPathReferences(buildPathReferences, projectsProcessed, false); record = (ITaglibRecord) buildPathReferences.get(reference); } Now the problem is that the addBuildPathreferences will start to go through all dependent projects and call TaglibIndex.getInstance().createDescription(buildpathProjects[i]); more often than the size of the project descriptions cache limit. So it will continously throw out already resolved project descriptions. The odd thing is in our case that actually the reference could be resolved already after creating the second project description and looking into description.fImplicitReferences. So it is overkill to continue loading all the other project descriptions. Perhaps the addBuildPathreferences should get the reference as parameter and if it is not null (same method is used on another place, where really ALL projects should be iterated through, so parameter could be set to null), then as soon as the reference is found stop iterating through the next projects. Perhaps both suggestions should be implemented and I think they will really help developers, who need to have >8 projects open at a time and work with JSPs and taglibs.
Created attachment 179553 [details] Dump of Main-thread each 20 secs during a 5 min JSP loading
Note that this bug appears not to be limited to LINUX platform. I have the exact same problem with Helios on Windows 64. The problem does not occur on my most recent Galileo workspaces. JSPF files do not seem to suffer the same problem: only JSP. This is with all validators disabled.
Just for kicks I saved a medium sized JSP that was taking about 2 minutes to load, as a JSPF. When I went to open the newly saved JSPF, it too took about 2 minutes at 100% CPU (thank goodness for multi-core CPUs). Hence, it is not limited to JSP but related to the contents. Our workspace has about 40 projects and this particular file as approx 20 <%@page import= statements, a few <%@ include file= statements, a lot of javascript, many custom tags, and a smattering of scriptlets. Based on the above, I followed my nose and traced the problem back to a single JSPF file that ONLY contains taglib statements. The file is only 14 lines long and contains 14 <%@ taglib uri= statements. This tiny file takes about 2 minutes at 100% CPU to open. I hope this helps.
Sounds like this is a duplicate of/by bug 326332, then, among other issues being investigated.
Currently this bug prevents me from editing JSP-pages. Is there a quick (and/or dirty) solution to this bug without recompiling eclipse? Perhaps * disable some plugins * install a snapshot plugin * replace a classfile in a jar Or do I have to use another IDE? Regards Lars
Created attachment 180339 [details] feature patch Our first service release has already shipped. In the meantime (Helios SR2 is slated for Feb. 25, 2011), I've created a feature patch that includes the fix from Bug 326332. To install this feature patch: 1. Close Eclipse 2. Unzip org.eclipse.jst.jsp.core.featurepatch.zip into your eclipse\ directory (e.g., C:\dev\helios\eclipse) 3. You should end up with a new feature in the features\ directory (org.eclipse.jst.jsp.core.featurepatch_1.0.0) and a new plug-in in the plugins\ directory (org.eclipse.jst.jsp.core_1.2.302.v201010061038.jar) 4. Launch Eclipse 5. Double check and make sure that Help > About Eclipse , Installation Details , Plugins has loaded the right version of org.eclipse.jst.jsp.core (1.2.302.v201010061038.jar) This should clear up the problem for you.
This is a duplicate of Bug 326332. We've disabled the limit on the cache size. We're already capable of responding to low-memory events. The limited cache created an additional overhead that was unnecessary. Thanks for bringing this to our attention. Please see comment 10 for installing the feature patch that contains the fix from Bug 326332 for Helios. *** This bug has been marked as a duplicate of bug 326332 ***
(In reply to comment #10) > Created an attachment (id=180339) [details] > feature patch > Just to clarify, this feature patch is against SR1 of Helios.
Lars(In reply to comment #10) Hi Nick, thanks a lot for the quick (and non-dirty;)) workaround. And it works. Just one question: do I have to revert the change manually if I install SR2 in Feb via the Eclipse update func or is this done automatically? Thanx and regards
(In reply to comment #13) > Lars(In reply to comment #10) > > Hi Nick, > thanks a lot for the quick (and non-dirty;)) workaround. And it works. > > Just one question: do I have to revert the change manually if I install SR2 in > Feb via the Eclipse update func or is this done automatically? > > Thanx and regards Hi Lars, You're welcome. I'm pretty sure that when you update, this feature patch will deactivate since it references the existing feature version of 3.2.2 and the installed feature will have a higher version number in SR2.
The patch works a treat on my Windows Vista machine. Thanks, much appreciated :). (In reply to comment #14) > (In reply to comment #13) > > Lars(In reply to comment #10) > > > > Hi Nick, > > thanks a lot for the quick (and non-dirty;)) workaround. And it works. > > > > Just one question: do I have to revert the change manually if I install SR2 in > > Feb via the Eclipse update func or is this done automatically? > > > > Thanx and regards > > Hi Lars, > > You're welcome. > > I'm pretty sure that when you update, this feature patch will deactivate since > it references the existing feature version of 3.2.2 and the installed feature > will have a higher version number in SR2.
I'm having trouble with the patch from comment #10. I followed the steps and verified that the feature/plugin artifacts end up in the appropriate directory. But when I load eclipse and go to Installation Details, I still see the old version of org.eclipse.jst.jsp.core (1.2.300.v201005271731). And the performance of the JSP editor is still as bad as before. I tried starting eclipse like this: eclipse.exe -clean That didn't seem to help. Is there anything I else I should try? In case it helps, I'm on 64-bit Win7 but using 32-bit eclipse.
Perhaps I can help... Are you using the SR1 version of Helios? If not, I think the fix might be specifically targeting SR1 release, not the original release of Helios. You might want to do a "check for updates" to ensure you're using SR1. In my Eclipse/plugins directory I have two versions of the jar org.eclipse.jst.jsp.core_1.2.302.v201008251735.jar (and old one, but not as old as the version you mention). org.eclipse.jst.jsp.core_1.2.302.v201010061038.jar Within my features directory I have a folder named org.eclipse.jst.jsp.core.featurepatch_1.0.0 which contains a single file called feature.xml. Hope this is of some assistance. I'm just glad to having JSP editing back! Cheers Troy (In reply to comment #16) > I'm having trouble with the patch from comment #10. > > I followed the steps and verified that the feature/plugin artifacts end up in > the appropriate directory. > > But when I load eclipse and go to Installation Details, I still see the old > version of org.eclipse.jst.jsp.core (1.2.300.v201005271731). > > And the performance of the JSP editor is still as bad as before. > > I tried starting eclipse like this: eclipse.exe -clean > That didn't seem to help. > > Is there anything I else I should try? > > In case it helps, I'm on 64-bit Win7 but using 32-bit eclipse.
Excellent explanation, Troy. Thanks for helping to clarify so quickly. Yes, this patch is indeed against Helios SR1 (see comment 12). (In reply to comment #17) > Perhaps I can help... > Are you using the SR1 version of Helios? If not, I think the fix might be > specifically targeting SR1 release, not the original release of Helios. > You might want to do a "check for updates" to ensure you're using SR1. > > In my Eclipse/plugins directory I have two versions of the jar > > org.eclipse.jst.jsp.core_1.2.302.v201008251735.jar (and old one, but not as old > as the version you mention). > org.eclipse.jst.jsp.core_1.2.302.v201010061038.jar > > Within my features directory I have a folder named > org.eclipse.jst.jsp.core.featurepatch_1.0.0 > which contains a single file called feature.xml. > > Hope this is of some assistance. > I'm just glad to having JSP editing back! > > Cheers > Troy > > > (In reply to comment #16) > > I'm having trouble with the patch from comment #10. > > > > I followed the steps and verified that the feature/plugin artifacts end up in > > the appropriate directory. > > > > But when I load eclipse and go to Installation Details, I still see the old > > version of org.eclipse.jst.jsp.core (1.2.300.v201005271731). > > > > And the performance of the JSP editor is still as bad as before. > > > > I tried starting eclipse like this: eclipse.exe -clean > > That didn't seem to help. > > > > Is there anything I else I should try? > > > > In case it helps, I'm on 64-bit Win7 but using 32-bit eclipse.
You're totally right - I thought I was using SR1 but I wasn't. I have 3 different version of Eclipse side-by-side and evidently I wasn't using the one I thought I was using. I installed a fresh copy of SR1 and now I see the following in my plugins directory: ... org.eclipse.jst.jsp.core_1.2.302.v201008251735.jar org.eclipse.jst.jsp.core_1.2.302.v201010061038.jar ... And I see the following folder in my features directory: ... org.eclipse.jst.jsp.core.featurepatch_1.0.0 ... This one is a folder with a single XML file in it. Still, when I launch Eclipse and open Installation Details, I see this entry: Eclipse Web Tools Platform - Structured Source JSP Model - 1.2.302.v201008251735 - org.eclipse.jst.jsp.core I tried the following: * Check for Updates (none) * Starting with -clean * New workspace * Yet another fresh install of SR1 * Renaming the old jar to something different None of these things helped. Can anyone think of anything else I should try? Thanks
(In reply to comment #19) > Can anyone think of anything else I should try? I have noticed there are sometimes problems with patches being applied, if they are simply unzipped to an install (reported in bug 326735). You might try installing the patch with p2. Luckily, since Nick apparently hasn't learn yet how to check the box that says 'generate metadata' :) you can still use p2 with the "raw' patch feature and bundle in the zip. Unzip that zip file into its own (temporary) directory, say C:\patchdir. Then in your IDE, "install new software", "Add ...", "Local ..." and browse to or paste in your patchdir. You'll need to uncheck "show categories" box, but then should see exactly one feature to install Perhaps this p2 based code will get it installed properly for you? P.S. best not to use -clean any more ... it is less needed than it used to be, and 2) it can mess things up, in theory, by removing some types of init/config data that your package might need (though doubt that's related to your current problems). HTH
David - thanks for your help! Initially when I tried to follow your suggestion, it didn't work. I was able to select the patch from c:\temp\patchdir, but when I clicked to install it I got: "JSP Core Feature Patch" is not applicable to the current configuration and will not be installed. But eventually I was able to install the patch by doing two more things: 1. Removing the old feature/plugin artifacts that I'd placed manually 2. Running Eclipse as admin (on win7) After doing these two things and then repeating the patch installation steps, it seemed to work. Now when I look at Installed Software I see the correct new version. Hurray! I don't need to switch to Notepad++ for my JSP files anymore! :-) BTW, there might be another bug here were there was (apparently) some kind of permission issue, but the message I got didn't convey this ("not applicable...because of insufficient permission?")
(In reply to comment #21) > 2. Running Eclipse as admin (on win7) I know there's been some issues reported about that (such as bug 320383) ... and not sure what the "fix" actually was in Helios SR1; if you simply can do it now, or if on windows 7 you are supposed to first install as Administrator when you install into "Program Files" ... but glad you can use JSP editor again. Thanks for letting us know.
*** Bug 327871 has been marked as a duplicate of this bug. ***
*** Bug 335148 has been marked as a duplicate of this bug. ***
*** Bug 335314 has been marked as a duplicate of this bug. ***
*** Bug 335755 has been marked as a duplicate of this bug. ***
Was this fix included in SR-2? I am running Eclipse Java EE IDE for Web Developers Helios SR-2 and this bug occured twice now. I open a 200 lines long JSP file and Eclipse freezes for some minutes, using 100% of a CPU core. I did a find updates yesterday and it reported none.
(In reply to comment #27) > Was this fix included in SR-2? > > I am running Eclipse Java EE IDE for Web Developers Helios SR-2 > and this bug occured twice now. > > I open a 200 lines long JSP file and Eclipse freezes for some minutes, using > 100% of a CPU core. > > I did a find updates yesterday and it reported none. Yes. The fix is present in SR2. What version of org.eclipse.jst.jsp.core is being picked up by your install? Do you happen to have a stackdump of what was going on at the time of 100% CPU usage?
(In reply to comment #28) > (In reply to comment #27) > > Was this fix included in SR-2? > > > > I am running Eclipse Java EE IDE for Web Developers Helios SR-2 > > and this bug occured twice now. > > > > I open a 200 lines long JSP file and Eclipse freezes for some minutes, using > > 100% of a CPU core. > > > > I did a find updates yesterday and it reported none. > > Yes. The fix is present in SR2. > > What version of org.eclipse.jst.jsp.core is being picked up by your install? > Do you happen to have a stackdump of what was going on at the time of 100% CPU > usage? You can get a stackdump in a couple ways. If it's available to you, jstack will output the stack traces. Additionally, you could add the -debug flag when launching eclipse and then press Ctrl+Break in the console. That should output everything to a text file.
Created attachment 195505 [details] Stack dump when the bug occurs
Can you attach the (zipped) contents of your workspace's .metadata/.plugins/org.eclipse.jst.jsp.core/taglibindex directory?
Created attachment 195521 [details] taglibindex directory
Comment on attachment 195521 [details] taglibindex directory 7z is much smaller than ZIP...
(In reply to comment #33) > 7z is much smaller than ZIP... Perhaps, but it's not what I asked for, and I'll have to install something to read it.
(In reply to comment #33) > Comment on attachment 195521 [details] > taglibindex directory > > 7z is much smaller than ZIP... Based on the contents of your taglib index, this looks like a different problem. We'll need a new bug for this I think. You may be able to clear up your performance problem by shutting down your Eclipse instance and deleting the workspace's .metadata/.plugins/org.eclipse.jst.jsp.core/taglibindex directory. Then start up Eclipse again.
David, please see Bug 345778, which I've opened to address your issue.
