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.
Build: NetBeans IDE 7.1.1 (Build 201203012225) VM: Java HotSpot(TM) Client VM, 22.1-b02, Java(TM) SE Runtime Environment, 1.7.0_03-b05 OS: Windows 7 User Comments: GUEST: Debugging a main Class while another Project was in Debugging Mode GUEST: Compilando aplicacion Maximum slowness yet reported was 97499 ms, average is 32223
Created attachment 117354 [details] nps snapshot
The current snapshot come from web project, there are also j2se projects snapshots but issue was created for the web one. Because of the BaseActionProvider shared among the web and j2se there is no compatible way how to fix it. The only fix is the reschedule the invokeAction from EDT to RP in BAP but it breaks all the clients as they expect EDT. It can be done but both web, j2ee and j2se has to agree on it.
Sounds like good thing to do. j2ee agrees to your proposal. :-) What do you think may/will get broken?
Has there been any progress in rescheduling off the EDT?
I had a look at it but the code is little bit obfuscated for me and probably somebody from J2SE team would be more qualified to change it. :-) There is one thing I do not understand: An action which requires Java Model is called via ScanDialog.runWhenScanFinished and this method requires to be called from the AWT and executes given runnable in the AWT too. Yet in http://statistics.netbeans.org/exceptions/exception.do?id=577354 I can see that code executed from ScanDialog.runWhenScanFinished resulted into more scanning which blocks user for 15 seconds. What's the point of calling ScanDialog.runWhenScanFinished then in first place? Could it be just removed? Anyway I tried to rewrite it so that the action execution is posted into a new RP while preserving most of the existing logic as is. I tested and it seems to work but I would not be surprised if something got broken. On the other hand looking at J2SEActionProvider and WebActionProvider they do not have any "isAWTThread" expectations. Tomas, what do you think of the attached patch? I'm not very fond of it to be honest.
Created attachment 127821 [details] an idea to explore
Created attachment 127825 [details] different solution This is a different solution which I like more (apart from super ugly showProgressBarWhileScanningIsInProgress). It simplifies the logic though and should be still correct if I got the existing code right.
The J2SEActionProvider and probably the WebActionProvider too require EDT. The showMainClassWarning called from invokeAction:484->getTargetNames:886 creates a dialog asking an user about the main class and is synchronous it returns the main class. So it needs to be run from EDT, there will be a need to do SwingUtilities.invokeAndWait which nearly always ends with deadlock. I've talked about this issue with Jesse long time ago and probably the only correct solution is an API change.
(In reply to comment #8) > The showMainClassWarning called from invokeAction:484->getTargetNames:886 Good point. I overlooked that one. I will try to refactor the code little bit and split what is done when. For example all the checks resulting into an AWT message box should be done first directly in the AWT before action gets executed on background. If some action needs to check something expensive like for example validity of a main class then that should happen in AWT too; I mean AWT should show "checking validity of main class" while in separate thread main class validity is checked against the java model. But after all these initial checks are done the action should be executed on background and showing anything in UI should be forbidden. That should work no?
Yes, this will work. It can be either done by splitting the current code or by API change: adding some invokeInBackground into ActionProvider2.