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 Dev (Build 200908022240) VM: Java HotSpot(TM) Client VM, 14.0-b16, Java(TM) SE Runtime Environment, 1.6.0_14-b08 OS: Windows Vista, 6.0, x86 User Comments: jfarjona: Changed the signature of a function in another object. Seems that it gets stuck re-building internally ? Maximum slowness yet reported was 30839 ms, average is 30839
Created attachment 87567 [details] nps snapshot
J2EE please check why this happens and whether something is wrong on your side or ours.
Not in j2ee, this looks related to jmx module, which is on the update center.
Hi, could you provide a bit of context. How to use an nps snapshot? Where the time is spent? Thanks.
Just open the nps snapshot in NetBeans (menu Profile | Load Snapshot). See also http://wiki.netbeans.org/FitnessViaPostMortem As for this particular snapshot, it looks like not much time is spent in AWT Event Queue thread, but it's because it is waiting. This snapshot is still in the older format where it is more difficult to find out what a thread is waiting for. When you have the snapshot opened, expand AWT-EventQueue-1 thread, then scroll down and on the last expanded node invoke "Show Subtree" from context menu. In the subtree view press Ctrl+F and search for Unsafe.park. Then you'll see that the AddAttrAction when being enabled causes java source parsing - which is the problem, parsing should be run in AWT thread, especially not for things like enabling actions that must be really fast.
Thanks, I can see the stack. You say that parsing should be run in AWT thread, I guess that you mean should not. Right? In order to enable or not these actions we need to do this parsing. So we need some way to wait until this parsing is done before to return from enable() method. What is the right way to achieve this. Thanks. JF
Yes, parsing should *not* run in AWT thread, it was a typo. As for how to do this correctly, it is not that easy. Basically when you identify that you need to check the action enabling, you should do it in a separate (background) thread and set the action state when it completes. This means that until you know, the action should look like enabled and if someone invokes it too early then you need to wait for the task to finish. So it may happen the user clicks an action that in fact should be disabled (it is just not known yet) - in such case you'd have to tell the user. But the cases when this runs for long time should be limited, probably only when it waits for initial scan of sources or an up-to-date check. But as you can see from this report, sometimes it can be quite long, so it should definitely not block entire application - just because some action needs to determine if it is enabled or not. Another option is to think if there is not some other way to determine if the class is MBean that would not require java source infrastructure (I'm not able to tell).
Created attachment 92317 [details] nps snapshot