Community
Participate
Working Groups
We try to call WTP Web service's CreateModuleCommand to create an EJB project, that command has an algorithm as follow: IFacetedProject fproject = ProjectFacetsManager.create(projectName, null, monitor_); // calculate facets to add ... Set actions = FacetUtils.getInstallActions(facetsToAddModified); fproject.modify(actions, monitor_); fproject.modify() hangs the whole Web service wizard. Rupam and I have debugged into the call and find out the blocker job is from J2EE, with the name of "Update the Navigator Content Viewer Job". Rupam and I tried to run the same scenario in the Resource view and we did not run into the same problem any more. One observation we made was that FacetedProject.modify need to use the whole WorkspaceRoot as a scheduling rule. I will send you the stack trace I have.
Would the change to FacetedProject.modify() resolve the scenario? Kosta, any thoughts? If this is a navigator issue, I can try and reproduce.
Without the stack dumps at the time of deadlock, this canot procede any further. The faceted project api has gone through extensive locking strategy and deadlock potential analysis. That's not to say there aren't possibly other bugs out there, but without the stack traces we could be doing more harm than good. Also, even if the problem is well understood in the next couple of days, a solution is likely to be too risky for 1.0.1.
Kelvin, can you send the dump with all of the threads to Kosta, or attach it here?
Kelvin, this is a long shot (doubly so having not seen the stack trace) but you might want to try calling modify() from a secondary thread. The Web services platform has generated deadlock conditions in the past when calling API on Server tools to publish or start servers from the primary (UI) thread. I won't get into the gory reasons why, but the snippet of code below solved our problems. The cause of your deadlock could be quite different so there's no guarantee this will work for you, but it's worth a shot... ... try { IRunnableWithProgress runnable = new IRunnableWithProgress() { public void run (IProgressMonitor monitor) throws InvocationTargetException, InterruptedException { fproject.modify(...); } }; PlatformUI.getWorkbench().getProgressService().run(true,false,runnable); } catch (...) { ... } ...
Added to the 1.0.1 hot list and setting priority to P2.
Discussed with Jeffrey, this does not need to go into 101 and can be deferred to 102.
This is the Thread dump when I ran against WTP wtp-sdk-M200602131328.zip. Although this was not 100% reproducable every time, I found that it will be easier to run into this when I got more things open in the J2EE Navigator in the J2EE perspective. I will attach my test plugin shortly. It is a 2 page wizard, and once next is clicked, it copy some Java files and J2EE Web service deployment descriptors into an existing EJB project, it also tries to create another EJB project after these files are copied over. The hanging occurs at ProjectFacetsManager.create() when this is called from the wizard (main UI thread). Full thread dump Java HotSpot(TM) Client VM (1.4.2_08-b03 mixed mode): "Worker-4" prio=5 tid=0x25961e48 nid=0xb40 in Object.wait() [2607f000..2607fd88] at java.lang.Object.wait(Native Method) - waiting on <0x1164d9f8> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:173) - locked <0x1164d9f8> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.startJob(WorkerPool.java:20 5) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:69) "Worker-3" prio=5 tid=0x2497f8b8 nid=0x130 waiting on condition [2582f000..2582f d88] at java.lang.Thread.sleep(Native Method) at org.eclipse.ui.internal.decorators.DecorationScheduler$1.run(Decorati onScheduler.java:249) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:76) "Worker-2" prio=5 tid=0x24974810 nid=0x9cc in Object.wait() [257df000..257dfd88] at java.lang.Object.wait(Native Method) - waiting on <0x1164d9f8> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:173) - locked <0x1164d9f8> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.startJob(WorkerPool.java:20 5) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:69) "Worker-1" prio=5 tid=0x24438670 nid=0xa6c in Object.wait() [2579f000..2579fd88] at java.lang.Object.wait(Native Method) - waiting on <0x1164d9f8> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:173) - locked <0x1164d9f8> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.startJob(WorkerPool.java:20 5) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:69) "Java indexing" daemon prio=4 tid=0x247529c0 nid=0xa58 in Object.wait() [2570f00 0..2570fd88] at java.lang.Object.wait(Native Method) - waiting on <0x11892150> (a org.eclipse.jdt.internal.core.search.indexi ng.IndexManager) at java.lang.Object.wait(Unknown Source) at org.eclipse.jdt.internal.core.search.processing.JobManager.run(JobMan ager.java:349) - locked <0x11892150> (a org.eclipse.jdt.internal.core.search.indexing.I ndexManager) at java.lang.Thread.run(Unknown Source) "Worker-0" prio=5 tid=0x245118f0 nid=0xae4 in Object.wait() [2555f000..2555fd88] at java.lang.Object.wait(Native Method) - waiting on <0x1164d9f8> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.sleep(WorkerPool.java:173) - locked <0x1164d9f8> (a org.eclipse.core.internal.jobs.WorkerPool) at org.eclipse.core.internal.jobs.WorkerPool.startJob(WorkerPool.java:20 5) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:69) "Start Level Event Dispatcher" daemon prio=5 tid=0x009b7ce0 nid=0xa40 in Object. wait() [2461f000..2461fd88] at java.lang.Object.wait(Native Method) - waiting on <0x1146d908> (a org.eclipse.osgi.framework.eventmgr.EventMa nager$EventThread) at java.lang.Object.wait(Unknown Source) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.getNextE vent(EventManager.java:349) - locked <0x1146d908> (a org.eclipse.osgi.framework.eventmgr.EventManage r$EventThread) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(Even tManager.java:287) "Framework Event Dispatcher" daemon prio=5 tid=0x009ca7f0 nid=0x45c in Object.wa it() [245df000..245dfd88] at java.lang.Object.wait(Native Method) - waiting on <0x1146d958> (a org.eclipse.osgi.framework.eventmgr.EventMa nager$EventThread) at java.lang.Object.wait(Unknown Source) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.getNextE vent(EventManager.java:349) - locked <0x1146d958> (a org.eclipse.osgi.framework.eventmgr.EventManage r$EventThread) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(Even tManager.java:287) "State Data Manager" daemon prio=5 tid=0x009a5008 nid=0x9a4 waiting on condition [2459f000..2459fd88] at java.lang.Thread.sleep(Native Method) at org.eclipse.osgi.framework.adaptor.core.StateManager.run(StateManager .java:293) at java.lang.Thread.run(Unknown Source) "Signal Dispatcher" daemon prio=10 tid=0x0091adb8 nid=0x384 waiting on condition [0..0] "Finalizer" daemon prio=9 tid=0x00918328 nid=0x394 in Object.wait() [2422f000..2 422fd88] at java.lang.Object.wait(Native Method) - waiting on <0x113c0138> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(Unknown Source) - locked <0x113c0138> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(Unknown Source) at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source) "Reference Handler" daemon prio=10 tid=0x00916f50 nid=0x200 in Object.wait() [24 1ef000..241efd88] at java.lang.Object.wait(Native Method) - waiting on <0x113c01a0> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Unknown Source) at java.lang.ref.Reference$ReferenceHandler.run(Unknown Source) - locked <0x113c01a0> (a java.lang.ref.Reference$Lock) "main" prio=7 tid=0x00236450 nid=0xb30 in Object.wait() [6e000..6fc3c] at java.lang.Object.wait(Native Method) - waiting on <0x11c97b90> (a org.eclipse.core.internal.jobs.ThreadJob) at org.eclipse.core.internal.jobs.ThreadJob.joinRun(ThreadJob.java:183) - locked <0x11c97b90> (a org.eclipse.core.internal.jobs.ThreadJob) at org.eclipse.core.internal.jobs.ImplicitJobs.begin(ImplicitJobs.java:8 8) at org.eclipse.core.internal.jobs.JobManager.beginRule(JobManager.java:1 90) at org.eclipse.core.internal.resources.WorkManager.checkIn(WorkManager.j ava:96) at org.eclipse.core.internal.resources.Workspace.prepareOperation(Worksp ace.java:1676) at org.eclipse.core.internal.resources.Project.open(Project.java:785) at org.eclipse.wst.common.project.facet.core.internal.ProjectFacetsManag erImpl.create(ProjectFacetsManagerImpl.java:418) at org.eclipse.wst.common.project.facet.core.ProjectFacetsManager.create (ProjectFacetsManager.java:346) at test.kelvin.facetedproject.wizards.utils.Utils.createFacetedProject(U tils.java:39) at test.kelvin.facetedproject.wizards.SampleNewWizardPage.getNextPage(Sa mpleNewWizardPage.java:198) at org.eclipse.jface.wizard.WizardDialog.nextPressed(WizardDialog.java:7 47) at org.eclipse.jface.wizard.WizardDialog.buttonPressed(WizardDialog.java :345) at org.eclipse.jface.dialogs.Dialog$2.widgetSelected(Dialog.java:556) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java: 90) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:843) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3125) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2758) at org.eclipse.jface.window.Window.runEventLoop(Window.java:809) at org.eclipse.jface.window.Window.open(Window.java:787) at org.eclipse.ui.actions.NewWizardAction.run(NewWizardAction.java:181) at org.eclipse.ui.actions.NewWizardDropDownAction.run(NewWizardDropDownA ction.java:174) at org.eclipse.jface.action.Action.runWithEvent(Action.java:996) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection (ActionContributionItem.java:538) at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContri butionItem.java:488) at org.eclipse.jface.action.ActionContributionItem$6.handleEvent(ActionC ontributionItem.java:441) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:843) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3125) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2758) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1699) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1663) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.jav a:367) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:143) at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:10 3) at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformAct ivator.java:226) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.ja va:376) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.ja va:163) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.eclipse.core.launcher.Main.invokeFramework(Main.java:334) at org.eclipse.core.launcher.Main.basicRun(Main.java:278) at org.eclipse.core.launcher.Main.run(Main.java:973) at org.eclipse.core.launcher.Main.main(Main.java:948) "VM Thread" prio=5 tid=0x00959560 nid=0xb44 runnable "VM Periodic Task Thread" prio=10 tid=0x0091d800 nid=0xac8 waiting on condition "Suspend Checker Thread" prio=10 tid=0x0091a250 nid=0xb0c runnable
I don't see a deadlock in this thread dump. The main UI thread is doing an IProject.open, which is waiting trying to acquire the scheduling rule, but all the other threads seem to be idle (unless I am missing something). Anyone else care to take a look? BTW, doing resource operations out of the ui thread is generally a bad idea. You should be spinning off a separate thread and waiting for that thread to finish while processing the ui update events. You may be able to use WizardDialog.run method to do this. If the first parameter is set to true, the method will fork off a thread and wait (while continuing to process events). It's used during performFinish, so you would have to research whether it can be called midstream on page navigation.
Note that the thread dump does not correspond to the original problem report.
Created attachment 34670 [details] Sample wizard to create project on the main UI thread After running this experiment repeatedly, it turns out that the hanging is more likely to happen at ProjectFacetsManager.create() rather than IFacetedProject.modify(). This sample code is a simulation of what an adopter can encounter in the WTP Web service wizard. I believe the WTP Web service team would also like input from the API owner on whether it is safe to call ProjectFacetsManager.create() and other Facet API on the main UI thread. As of today, they are creating project in the main UI thread. To launch, you need to pre-create an EJB project “tempEjb” with “ejbModule” present. Make sure you are not pre-selecting anything in the workspace and you are in the J2EE perspective, you can launch the wizard by New Wizard -> Sample Wizards -> Multi-page Editor file. You would need to enter something in the “Container” on the wizard (which would be the name of the EJB project to be created), press next to run the project creation logic. You might not be able to run into this the first time. What I ended up doing was that after I run the wizard, I renamed tempEjb to something else, then created tempEjb again and rerun the wizard. Between each run, I also tried to open as many folders/artifacts on the J2EE Naviagator view as possible.
> This sample code is a simulation of what an adopter can encounter in the WTP Web service wizard. I believe the WTP Web service team would also like input from the API owner on whether it is safe to call ProjectFacetsManager.create() and other Facet API on the main UI thread. As of today, they are creating project in the main UI thread. It depends on whether the particular api can cause a resource change. For instance, it's perfectly safe to call the version of ProjectFacetsManager.create() that takes an existing faceted IProject and returns an IFacetedProject wrapper. However, it is not safe to call the varient of create that takes the project name and creates the project on disk. Another example. It's ok to call IFacetedProject.hasProjectFacet() on the UI thread, but IFacetedProject.modify() should never be called from the UI thread. By the way, the above is true of all eclipse api, not just for the faceted project.
Setting the target milestone on this bug is not appropriate at this point. It's not clear yet whether this is a framework bug or a bug in the calling code. Not sure if Kelvin tried yet or not to move his calling code out of the main UI thread. Even if end up agreening that this is a framework issue, whether this is appropriate for the 1.0.2 milestone will depend on (a) how often it occurrs and whether there is a workaround, and (b) how safe is the fix. Until we know more, this bug should remain untargetted.
Konstantin, Could you please assign this bug to component jst.ws and user rsinha@ca.ibm.com and target it to 1.0.2. Changing Web services wizard code to call ProjectFacetsManager.create() and IFacetedProject.modify() on a different thread from the UI thread solves the problem. Thanks.
Created attachment 34942 [details] apply to org.eclipse.jst.ws.consumption patch 1 of 1
The attached patch is ready to be committed.
Bug 126757 has been committed to HEAD. It will be released later on today to this week's integration build. It has not been committed to the R1_0_maintenance branch yet since we want to make sure WTP 1.0.1 goes out the door first.
Released to HEAD as v200602221946.
Per Kathy's request, adding a comment about which facet API calls have to be run on a separate thread: According to Konstantin, these should not be run on the UI thread: ProjectFacetsManager: - public static IFacetedProject create( final String name, final IPath location, final IProgressMonitor monitor ) throws CoreException IFacetedProject: - void modify( Set actions, IProgressMonitor monitor ) throws CoreException - void setFixedProjectFacets( Set facets ) throws CoreException - void setRuntime( IRuntime runtime, IProgressMonitor monitor ) throws CoreException BTW, I've opened bug 128109 asking for additional javadoc on the facet API.
Released to R1_0_Maintenance as v200602271844. This will be in this week's WTP 1.0.2 M build. Note that this had already been released HEAD and is already in the 02/24 WTP 1.5 I build.
verified in 1.0.2 and 1.5
Closed.
