This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
This is an attempt to fix issue #58057 correctly, without change in the behavior of debugger actions. The problem is, that the actions are launched in AWT thread, but they should not run in AWT, since they might need a long time to finish. As a solution of this, JPDA actions were moved into RequestProcessor. But this has the ugly side-effect, that ActionsManager.doAction() finishes sooner then the action even starts. This is a severe change in the behavior. We need to solve this via a "postAction()" method, that will just initiate the action and will notify after the action finishes.
Created attachment 23960 [details] The proposed change.
Please review this API change. It's a necessary support for asynchronous debugger actions.
I am missing the usecases. Can you update them? Who will call the new methods in ActionManager and why? Why should someone implement new methods in the action provider? One advice I might have is to change the way the ActionsProvider enhancement is done. Why not add new constructor that would take boolean argument saying whether all the actions from the provider are supposed to be sync or async? Would be nicer for api readers, imho. Especially in case where all/most actions from now are going to be async. The only complication is when few actions shall be async and few sync - then one need to register two providers, i guess... Of course, as you might expect, I request tests. Asynchronous behaviour cannot be implemented correctly without tests, so please write some, you will not be sorry in future.
> I am missing the usecases. See http://www.netbeans.org/servlets/ReadMsg?list=nbdev&msgNo=30086 Since debugger actions can take too long or possibly block, it's necessary to have them asynchronous. For JPDA actions, we solve this by posting them into RP. However, this approach is not suitable for other debugger implementation (we already went through a round of "please don't post actions on RP" once before). And also this approach changes the behavior, since ActionsManager.doAction() method is finished even before the action actually starts. The usecase is therefore to call ActionsManager.postAction() on AWT thread. See debuggercore/src/org/netbeans/modules/debugger/ui/actions/DebuggerAction.java in the attached diff. The impl. in ActionsProvider.postAction() must not block for a long time. ActionsManager.doAction() will stay there with the original blocking implementation and will not be called from AWT any more. Only programmatically. > Why should someone implement new methods in the action provider? In order not to have deadlocks of AWT. See issue #58057. > Why not add new constructor that would take boolean argument saying > whether all the actions from the provider are supposed to be sync or async? The ActionsManager has a static list of ActionProviders. It would have to create two instances of each - one sync for doAction(), one async for postAction(). Also, it retrieves ActionsProviders from a lookup. I can not imagine how to retrieve these two instances from the lookup. To do that, we would have to introduce a new abstract class ActionsProviderAsync (the ActionsProvider should have been an interface, shouldn't it??) This change approach seems to be simpler to me and when it's already an abstract class, we can add methods to it... > Of course, as you might expect, I request tests. We have unit tests for debugger actions in JPDA module. It should be easy to extend that for calling asynch actions...
Created attachment 24194 [details] The new diff with test included. Latest comments incorporated.
The latest patch contains also tests for the asynchronous actions and necessary changes in JPDA actions implementation. Thanks for the review, if there are no objections, I'll commit the change tomorrow.
Integrated in trunk: /cvs/debuggercore/src/org/netbeans/modules/debugger/ui/actions/DebuggerAction.java,v <-- DebuggerAction.java new revision: 1.9; previous revision: 1.8 /cvs/debuggercore/api/apichanges.xml,v <-- apichanges.xml new revision: 1.5; previous revision: 1.4 /cvs/debuggercore/api/manifest.mf,v <-- manifest.mf new revision: 1.10; previous revision: 1.9 /cvs/debuggercore/api/src/org/netbeans/api/debugger/ActionsManager.java,v <-- ActionsManager.java new revision: 1.19; previous revision: 1.18 /cvs/debuggercore/api/src/org/netbeans/spi/debugger/ActionsProvider.java,v <-- ActionsProvider.java new revision: 1.6; previous revision: 1.5 /cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/actions/ContinueActionProvider.java,v <-- ContinueActionProvider.java new revision: 1.9; previous revision: 1.8 /cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/actions/PauseActionProvider.java,v <-- PauseActionProvider.java new revision: 1.10; previous revision: 1.9 /cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/actions/PopToHereActionProvider.java,v <-- PopToHereActionProvider.java new revision: 1.13; previous revision: 1.12 /cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/actions/StepActionProvider.java,v <-- StepActionProvider.java new revision: 1.23; previous revision: 1.22 /cvs/debuggerjpda/src/org/netbeans/modules/debugger/jpda/actions/StepIntoActionProvider.java,v <-- StepIntoActionProvider.java new revision: 1.20; previous revision: 1.19 RCS file: /cvs/debuggerjpda/test/unit/src/org/netbeans/api/debugger/jpda/AsynchStepTest.java,v /cvs/debuggerjpda/test/unit/src/org/netbeans/api/debugger/jpda/AsynchStepTest.java,v <-- AsynchStepTest.java initial revision: 1.1 /cvs/debuggerjpda/test/unit/src/org/netbeans/api/debugger/jpda/JPDASupport.java,v <-- JPDASupport.java new revision: 1.16; previous revision: 1.15 RCS file: /cvs/debuggerjpda/test/unit/src/org/netbeans/api/debugger/jpda/testapps/AsynchStepApp.java,v /cvs/debuggerjpda/test/unit/src/org/netbeans/api/debugger/jpda/testapps/AsynchStepApp.java,v <-- AsynchStepApp.java initial revision: 1.1
Verified ... and Closing all issues resolved into NetBeans 6.7 and earlier.