Community
Participate
Working Groups
Build Identifier: M20110210-1200 When performing a refactoring in a project with JSP files the dialog hangs with a stack trace which ends at org.eclipse.wst.sse.core.indexing.AbstractIndexManager.waitForConsistent(AbstractIndexManager.java:376) Possibly related is an error which is logged: !ENTRY org.eclipse.core.jobs 4 2 2011-03-15 13:42:06.992 !MESSAGE An internal error occurred during: "Processing JSP changes since last activation". !STACK 0 java.lang.IllegalArgumentException: Path must include project and resource name: / at org.eclipse.core.runtime.Assert.isLegal(Assert.java:63) at org.eclipse.core.internal.resources.Workspace.newResource(Workspace.java:1801) at org.eclipse.core.internal.resources.Container.getFile(Container.java:207) at org.eclipse.wst.sse.core.indexing.AbstractIndexManager$ResourceEventProcessingJob.loadPreservedReceivedResourceEvents(AbstractIndexManager.java:1549) at org.eclipse.wst.sse.core.indexing.AbstractIndexManager$ResourceEventProcessingJob.start(AbstractIndexManager.java:1138) at org.eclipse.wst.sse.core.indexing.AbstractIndexManager.start(AbstractIndexManager.java:237) at org.eclipse.jst.jsp.core.internal.JSPCorePlugin$1.run(JSPCorePlugin.java:179) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1975) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1957) at org.eclipse.jst.jsp.core.internal.JSPCorePlugin$PluginInitializerJob.run(JSPCorePlugin.java:151) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Reproducible: Sometimes Steps to Reproduce: 1. Work on project with JSPs 2. Perform Java refactoring Please note that only Java files are affected, i.e. no JSP/taglib etc changes.
Created attachment 191203 [details] Thread dump
Additionally, canceling the dialog does not cancel the refactoring.
The problem is something either went wrong with preserving resource change events that happened just before a workspace shut down, or there is a problem reading back these preserved resource change events. In either case when the read back happens what ever path its reading is not valid and is causing the logged error which then causes start up to fail and leave the indexer in the "starting' state, then any task, such as refactoring, that waits on the starting to be finished is infinitely blocked. I am very surprised the cancel button did not work because the waitForConsistent rigorously checks the cancel state of the given progress monitor. Robert, Do you now hit this every time you open the affected workspace? If so I will have some further instructions/questions to work you around this issue and to help solve it on our end.
(In reply to comment #3) > Robert, Do you now hit this every time you open the affected workspace? If so I > will have some further instructions/questions to work you around this issue and > to help solve it on our end. Yes, I hit this every time after the logged error, which also manifests itself as an error dialog. Refactorings started in the brief interval between the Eclipse startup and the error dialog complete successfully.
(In reply to comment #4) > (In reply to comment #3) > > > Robert, Do you now hit this every time you open the affected workspace? If so I > > will have some further instructions/questions to work you around this issue and > > to help solve it on our end. > > Yes, I hit this every time after the logged error, which also manifests itself > as an error dialog. Refactorings started in the brief interval between the > Eclipse startup and the error dialog complete successfully. Robert, could you please grab a Thread dump after you have hit cancel? Also would it be possible for you to supply us with your workspace? And if not your workspace some workspace you can reproduce this on? If not that could you send us the file "YourWorkspace\.metadata\.plugins\org.eclipse.jst.jsp.core\jspsearch\.preservedResourceEvents". This file only contains the names of files and what happened to them (moved, deleted, added, etc) and is the file that is causing the error. As far as working around your issue I would suggest the following (if you are going to give us your workspace please do these steps AFTER zipping up your workspace to give to us): 1. delete the ""YourWorkspace\.metadata\.plugins\org.eclipse.jst.jsp.core\jspsearch\" directory 2. open your workspace 3. open the progress view 4. in the progress view use the little down arrow to open the preference and check the box to show sleeping operations 5. wait for the JSP indexing operations to finish before you close your workspace again 6. if your workspace is large this could take some time. the reason you need to wait for this to finish is that it seems you are hitting some bug with what we do to preserve un-processed events during a workspace shutdown when indexing is not yet finished.
Created attachment 191217 [details] .preservedResourceEvents from the workspace I am unable to provide a workspace, but I will try to reproduce the problem during this week. The project is medium-sized ( 1000 jsps ) so I will need to find another similar project.
Created attachment 191218 [details] Thread dump after pressing cancel in the 'Rename Method' dialog
Created attachment 191219 [details] Thread dump after pressing cancel in the progress dialog button in the bottom bar I initially hit this bug when performing the 'inline' rename, which does not bring up a dialog, but performs the refactoring straight away, with a progress indicator and cancel button in the status bar at the bottom. Just in case it makes a difference, I attach this thread dump as well.
(In reply to comment #8) > Created attachment 191219 [details] > Thread dump after pressing cancel in the progress dialog button in the bottom > bar > > I initially hit this bug when performing the 'inline' rename, which does not > bring up a dialog, but performs the refactoring straight away, with a progress > indicator and cancel button in the status bar at the bottom. > > Just in case it makes a difference, I attach this thread dump as well. Thank you much for all of the extra info, it will definitely help track down the issues.
Removing that file did the trick, so I can safely refactor again. Thanks.
(In reply to comment #10) > Removing that file did the trick, so I can safely refactor again. Thanks. If you didn't already I would suggest removing the entire folder. Otherwise the index maybe out of sync and missing some resources causing your re-factor and search actions to return incomplete results.
OK, thanks.
Created attachment 191540 [details] Fix Patch This patch fixes the following issues: * cancel not working because the wrong progress monitor was being passed to the index manager * a fail at startup should be dealt with more gracefully * if there is an exception while loading the '.preservedResourceEvents' file it should be caught, logged, and then handled, which means the workspace will need to be re-indexed ----- I can not figure out why this particular '.preservedResourceEvents' file got corrupted without some repeatable steps but at the very lease this patch will protect against such faults in the future and allow the index manager to recover gracefully.
Note this patch also address bug 339711.
Created attachment 191551 [details] Fix Patch - Update 1 Makes it so that BasicSearchQuery#doQuery is depreciated and calls a new doQuery(IProgressMonitor) so as not to break other people who are using this internal class.
Changes checked in. Thanks, Ian.
As we discussed, the doQuery() was fixed so that it was still called for those who may have subclassed BasicSearchQuery.
*** Bug 340676 has been marked as a duplicate of this bug. ***
