Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 210214 - LowPerformance took 21893 ms.
LowPerformance took 21893 ms.
Status: NEW
Product: javaee
Classification: Unclassified
Component: Web Project
All All
: P3 (vote)
: 7.2
Assigned To: David Konecny
EXCEPTIONS_REPORT perf-profileme 73-r...
Depends on:
Blocks: 222135
  Show dependency treegraph
Reported: 2012-03-27 15:38 UTC by js-java
Modified: 2017-02-20 03:18 UTC (History)
9 users (show)

See Also:
Issue Type: DEFECT

nps snapshot (90.51 KB, application/nps)
2012-03-27 15:39 UTC, js-java
an idea to explore (8.98 KB, patch)
2012-11-15 00:13 UTC, David Konecny
Details | Diff
different solution (6.33 KB, patch)
2012-11-15 00:36 UTC, David Konecny
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description js-java 2012-03-27 15:38:55 UTC
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
Comment 1 js-java 2012-03-27 15:39:03 UTC
Created attachment 117354 [details]
nps snapshot
Comment 2 Tomas Zezula 2012-03-27 16:44:36 UTC
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.
Comment 3 David Konecny 2012-04-05 05:13:45 UTC
Sounds like good thing to do. j2ee agrees to your proposal. :-) What do you think may/will get broken?
Comment 4 Petr Cyhelsky 2012-11-08 09:55:49 UTC
Has there been any progress in rescheduling off the EDT?
Comment 5 David Konecny 2012-11-15 00:12:24 UTC
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 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.
Comment 6 David Konecny 2012-11-15 00:13:21 UTC
Created attachment 127821 [details]
an idea to explore
Comment 7 David Konecny 2012-11-15 00:36:40 UTC
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.
Comment 8 Tomas Zezula 2012-11-16 14:31:48 UTC
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.
Comment 9 David Konecny 2012-11-19 03:48:02 UTC
(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?
Comment 10 Tomas Zezula 2012-11-19 10:56:15 UTC
Yes, this will work.
It can be either done by splitting the current code or by API change: adding some invokeInBackground into ActionProvider2.

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo