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.
I got an InvalidObjectException and then NB became EXTREMELY slow, but did NOT use noticable CPU. Not yet reproducable. Using NB 5.0 Beta 2 with JDK 5.0_06. Attaching messages.log and ThreadDump.
Created attachment 27925 [details] messages.log
Created attachment 27926 [details] ThreadDump
Just another note to clarify: I was not able to work with NB anymore. It just updated the window every now and then, when it had been covered with another window.
It looks like heavy java parsing activity. Reassigning for evaluation.
I don't see any heavy java parsing activity. Only icon resolver and error annotation are being updated. On the other hand I see VCS filesystem, which does some king of update and web debugger, which accesses FileSystems in AWT thread.
I don't understand, why it should be problem in the jspparser. In the thread dump there are only these threads running: Java Node State Updater Error Annotation Queue AWT-Windows CLI Requests Server Low Memory Detector Libor can you evaluate what is happen in the thread with jsp breakponts? I don't think, that this is the reason, but to be sure.
This was no jsp issue, because it is a J2SE project.
The original exception was thrown from the Java model. VCS and JSP debugger tasks were probably run on some window refreshing, thus at least the JSP debugger's activity is dumped only coincidentally. There should be made more exploration on the Java module side, beginning with the exploration of a reason of the original exception.
From Java module point of view the exception is harmless and moreover fixed. Please explain your actions in AWT thread.
JSP debugger only finds the FileObject currently selected. It is done by calling URLMapper.findFileObject(url). There is no other long time consuming action. Reassing to VCS team to evaluate.
VCS is not involved nearly at all - it just retrieves the file names upon a request from org.netbeans.modules.masterfs.MasterFileSystem.refresh(). The IDE is busy parsing sources - "Error Annotation Queue" thread + "Java Node State Updater". The code in "AWT-EventQueue-1" looks O.K. to me... Moving back where it came from...
Well, usually it's not a good idea to call methods that can access disk (like Utils.getFileObjectFromUrl()) in AWT thread. When the disk is busy, it will freeze the IDE for a while...
The questions to the reporter: Are you facing the problem repeatedly or did it occur only once? Cannot it be caused by the lack of memory? Did you try to increase a memory assigned to the NetBeans by using -Xmx parameter, e.g. -Xmx512M?
If I got it right from the dump the IDE was left and activated again - hence "Refresh-After-WindowActivated" task that is not quite cheap and does a lot of I/O. OTOH you can see it any time you switch to another app and back. So this one itself is not a culprit likely. It seems to me that you maybe also opened some editor (Alt-G or something) and this forces JavaNode updating where the search for main() is expensive due to access to disk in our MDR again. Javac parsing already runs too (no surprise). Refiring of changes from o.n.core.windows.RegistryImpl.doFirePropertyChange in o.n.m.debugger.projects.EditorContextImpl is not nice IMO too. There is yet another actions framework with expensive implementation. More thread dumps can give us better idea. Also the previous exception can be the key to the problem if the storage is in some uncertain state. Personally I do not see why this belongs to J2EE. Re memory: jstat or other monitoring tools can answer the question whether memory is a problem. Raising the mx randomly might not be a good idea.
InvalidObjectException is safe. Anyway - we need full messages.log to evaluate this bug properly. Tboerkel, please add it. We also appreciate, if you could attach several full thread dumps. Thanks.
Created attachment 28027 [details] messages.log complete
Added complete messages.log from that session. Cannot provide further thread dumps, because it was a one-time occurence.
Thanks for the messages.log. There are several interesting things there. 1. Old vcs modules are installed 2. There are many warnings from apisupport module 3. There is java.lang.OutOfMemoryError: Java heap space #3 is probably killer for the performance. Question is, who is guilty. CCing Tomas Hurka. If the problem was in gjast.jar, it is already fixed by fix of issue 63594.
Attaching another ThreadDump. Java Navigator says "Scanning in progress..." all the time, NB (Beta 2) takes 50% CPU all the time. Going on now for more than 15 minutes. Otherwise, NB is still responding quite normally. Nothing in messages.log.
And this time, no memory issue.
Created attachment 28119 [details] Another ThreadDump.
Was not able to shut down NB regularly after that (hangs at 0% of "Writing project classpath...".
Please attach full thread dump again to see if there are any new exceptions.
Sorry, too late for thread dump, already killed it. Attaching new messages.log.
Created attachment 28120 [details] Another messages.log.
It looks like there is some unfinished transaction. *** This issue has been marked as a duplicate of 65815 ***
Why is this a duplicate of a collab issue? I was not using collab.
Issue 65815 is java/javacore issue - not collab issue.
Reorganization of java component