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.

Bug 61542 - Add support for asynchronous debugger actions
Summary: Add support for asynchronous debugger actions
Status: CLOSED FIXED
Alias: None
Product: debugger
Classification: Unclassified
Component: Code (show other bugs)
Version: 5.x
Hardware: All All
: P2 blocker (vote)
Assignee: Martin Entlicher
URL:
Keywords: API, API_REVIEW_FAST
Depends on:
Blocks: 58911
  Show dependency tree
 
Reported: 2005-07-29 12:35 UTC by Martin Entlicher
Modified: 2010-04-29 09:24 UTC (History)
0 users

See Also:
Issue Type: TASK
Exception Reporter:


Attachments
The proposed change. (8.81 KB, patch)
2005-08-16 20:08 UTC, Martin Entlicher
Details | Diff
The new diff with test included. Latest comments incorporated. (25.43 KB, patch)
2005-08-24 16:59 UTC, Martin Entlicher
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Entlicher 2005-07-29 12:35:30 UTC
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.
Comment 1 Martin Entlicher 2005-08-16 20:08:04 UTC
Created attachment 23960 [details]
The proposed change.
Comment 2 Martin Entlicher 2005-08-16 20:09:42 UTC
Please review this API change. It's a necessary support for asynchronous
debugger actions.
Comment 3 Jaroslav Tulach 2005-08-17 10:50:48 UTC
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. 
 
Comment 4 Martin Entlicher 2005-08-18 20:02:31 UTC
> 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...
Comment 5 Martin Entlicher 2005-08-24 16:59:05 UTC
Created attachment 24194 [details]
The new diff with test included. Latest comments incorporated.
Comment 6 Martin Entlicher 2005-08-24 17:01:15 UTC
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.
Comment 7 Martin Entlicher 2005-08-25 16:50:39 UTC
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
Comment 8 Quality Engineering 2010-04-29 09:24:08 UTC
Verified ... and Closing all issues resolved into NetBeans 6.7 and earlier.