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 70575 - NB unresponsive after InvalidObjectException
Summary: NB unresponsive after InvalidObjectException
Status: RESOLVED DUPLICATE of bug 65815
Alias: None
Product: java
Classification: Unclassified
Component: Unsupported (show other bugs)
Version: 5.x
Hardware: All Windows ME/2000
: P2 blocker (vote)
Assignee: issues@java
URL:
Keywords: PERFORMANCE
Depends on: 50552
Blocks:
  Show dependency tree
 
Reported: 2005-12-19 07:58 UTC by tboerkel
Modified: 2007-09-26 09:14 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
messages.log (4.15 KB, text/plain)
2005-12-19 07:58 UTC, tboerkel
Details
ThreadDump (18.25 KB, text/plain)
2005-12-19 07:58 UTC, tboerkel
Details
messages.log complete (41.38 KB, text/plain)
2005-12-22 08:53 UTC, tboerkel
Details
Another ThreadDump. (31.04 KB, text/plain)
2006-01-02 10:28 UTC, tboerkel
Details
Another messages.log. (14.12 KB, text/plain)
2006-01-02 10:54 UTC, tboerkel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description tboerkel 2005-12-19 07:58:03 UTC
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.
Comment 1 tboerkel 2005-12-19 07:58:36 UTC
Created attachment 27925 [details]
messages.log
Comment 2 tboerkel 2005-12-19 07:58:58 UTC
Created attachment 27926 [details]
ThreadDump
Comment 3 tboerkel 2005-12-19 08:00:12 UTC
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.
Comment 4 Milan Kubec 2005-12-19 10:33:58 UTC
It looks like heavy java parsing activity. Reassigning for evaluation.
Comment 5 Jan Becicka 2005-12-19 15:59:49 UTC
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.
Comment 6 Petr Pisl 2005-12-19 16:45:12 UTC
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. 
Comment 7 tboerkel 2005-12-19 18:33:31 UTC
This was no jsp issue, because it is a J2SE project.
Comment 8 Libor Kotouc 2005-12-20 10:04:07 UTC
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.
Comment 9 Jan Becicka 2005-12-20 12:13:33 UTC
From Java module point of view the exception is harmless and moreover fixed.
Please explain your actions in AWT thread.
Comment 10 Libor Kotouc 2005-12-20 16:45:41 UTC
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.
Comment 11 Martin Entlicher 2005-12-20 16:58:59 UTC
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...
Comment 12 Martin Entlicher 2005-12-20 17:02:02 UTC
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...
Comment 13 Libor Kotouc 2005-12-20 17:18:18 UTC
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?
Comment 14 _ rkubacki 2005-12-21 08:00:57 UTC
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.
Comment 15 Jan Becicka 2005-12-22 07:54:23 UTC
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.
Comment 16 tboerkel 2005-12-22 08:53:30 UTC
Created attachment 28027 [details]
messages.log complete
Comment 17 tboerkel 2005-12-22 08:56:47 UTC
Added complete messages.log from that session. Cannot provide further thread
dumps, because it was a one-time occurence.
Comment 18 Jan Becicka 2005-12-22 14:20:05 UTC
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.
Comment 19 tboerkel 2006-01-02 10:27:57 UTC
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.
Comment 20 tboerkel 2006-01-02 10:28:27 UTC
And this time, no memory issue.
Comment 21 tboerkel 2006-01-02 10:28:54 UTC
Created attachment 28119 [details]
Another ThreadDump.
Comment 22 tboerkel 2006-01-02 10:32:17 UTC
Was not able to shut down NB regularly after that (hangs at 0% of "Writing
project classpath...".
Comment 23 Jan Becicka 2006-01-02 10:45:13 UTC
Please attach full thread dump again to see if there are any new exceptions.
Comment 24 tboerkel 2006-01-02 10:53:31 UTC
Sorry, too late for thread dump, already killed it. Attaching new messages.log.
Comment 25 tboerkel 2006-01-02 10:54:17 UTC
Created attachment 28120 [details]
Another messages.log.
Comment 26 Jan Becicka 2006-01-02 13:52:17 UTC
It looks like there is some unfinished transaction.

*** This issue has been marked as a duplicate of 65815 ***
Comment 27 tboerkel 2006-01-02 14:08:22 UTC
Why is this a duplicate of a collab issue? I was not using collab.
Comment 28 Jan Becicka 2006-01-03 08:42:55 UTC
Issue 65815 is java/javacore issue - not collab issue.
Comment 29 Quality Engineering 2007-09-20 10:30:03 UTC
Reorganization of java component