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.
Product Version = NetBeans IDE Dev (Build 200302030100) IDE Versioning = IDE/1 spec=3.34 impl=200302030100 Operating System = Linux version 2.4.18 running on i386 Java; VM; Vendor = 1.4.1_01; Java HotSpot(TM) Client VM 1.4.1_01-b01; Sun Microsystems Inc. Java Home = /usr/java/j2sdk1.4/sun/jdk1.4.1_01/jre System Locale; Encod. = cs_CZ; ISO-8859-2 Home Dir; Current Dir = /home.local/danielm; /DISKS/storage3/forte/NBdev-last/netbeans/bin ------------------------------------------------------------------------------- Well, I know thet you are not responsible if a user corrupts his data, but let me describe the situation how it happen and what impact it has wor me and my ide and then I hope you'll find this ide's behavoiur at least very annoying. And definitely it shoudl be solved as PERFORMANCE ISSUE/TASK or i'don't know to which category it belongs.... Description: ============ I have mounted whole sources of NetBeans (using Gen-CVS FS, but it isn't important in this context, IMO). And after a some time (can't tell you how long it is), ide became incredible slow:-( eating almost whole RAM and CPU at my OS... Thus I can't wark at all:-((( I've foun that at this time lots of stacktraces of Exceptions are printed into console. From their stacktraces I found that ide has problems when parsing .nbattrs files, especialy with at least this one: openide/test/qa-functional/src/DataLoaderTests/LoaderPoolTest/.nbattrs hmmm.... You could tell me, that I hadn't have commited it into repository 'cause there became uresolved conflicts after I updated my local sources of ide. But I didn't commited it into repository and definitely it shouldn't matter how it get inte repo...but we now know thet if something silamar is possible happen that it might coauses such nightmare like this one is.... I'm attaching the stacktrace of IOE. and SAXE. Exceptions I forgot to make FTD too:-( And till the conflicted file won't became parsed again I can't put it there... But I'll ASAP;-) thanks for understanding
Created attachment 8791 [details] E. stacktrqces
Jap...:-) From last restart it took approximately 2-3 hours to get almost stucked. Here's my FullThreadDump.....
Created attachment 8795 [details] FTD
And I've also got OOME:-(( *********** Exception occurred ************ at Tue Feb 04 15:30:44 CET 2003 [catch]java.lang.OutOfMemoryError *********** Exception occurred ************ at Tue Feb 04 15:30:44 CET 2003 Annotation: Exception occurred in Request Processor [catch]java.lang.OutOfMemoryError No stack available:-(
You are right, that there should be a way how recover from problems. But in this case I don't see any problem in DefaultAttributes as you probably expected. If file is corrupted, then null is returned according to API FileObject.getAttribute. Also ErrorManager is used to log it with informational severity. Moreover this value is softly cached. I would say that problem is not, that ErrorManager is used heavily, but that client code, that relies on attributes can't recover. Reassigned to vcscore. Please investigate thread dumpstack.
VCS modules (VcsFileSystem & JavaCvsFileSystem) use FileObject attributes to remember some information. Unfortunately this was implemented as a hack for some Forte EE module, but apparently it can cause performance problems. I'll try to find out whether I can remove these hacks. But IMHO this is not the biggest problem here. The problem is, that there are at least 3 exceptions thrown for every bad .nbattrs: 1) org.xml.sax.SAXParseException: The content beginning "<<" is not legal markup. Perhaps the "<" (c;) character should be a letter. at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3182) 2) org.xml.sax.SAXException: Cannot read DefaultAttributes. at org.openide.filesystems.DefaultAttributes$Table.readFromXML(DefaultAttributes.java:854) 3) java.io.IOException: Cannot read DefaultAttributes.: openide/test/qa-functional/src/DataLoaderTests/DataObjectTest/.nbattrs [catch] at org.openide.filesystems.DefaultAttributes.loadTable(DefaultAttributes.java:586) Throwing an exception affects the performance considerably. There's a question whether we can do something about it. According to what Radek said, there should not be these exceptions thrown repeatedly for every access to attributes. If this is so, it probably has no solution. The only way how to fix this is probably: do not access FileAttributes in children(). That actually means, that I have to remove the hack for Forte EE modules. I'll find out whether I can do it or not.
-> vcscore
I would like to remove the mentioned hack in 4.0, I will implement a replacement for it, which is not feasible to do in 3.5. So I'm proposing to "fix" this into 4.0 (the "fix" means, that I will not access the attributes in children(), but there's a question whether this would help anyway). Is this really P2? Versioning of .nbattrs is not recommended anyway and I don't thing many users do that. If there are conflicts it can bring other more serious issues.
Since the fix of issue #11589 can not be removed (it could theoretically be replaced with the fix of issue #31056, but there is no time to do the change and test it enough into 3.5), I will request a waiver for S1S 5.0 (NB 3.5)
Adding S1S5_WAV keyword. There is no way to fix this into NetBeans 3.5/S1S 5.0. I need to access file attributes to check some settings, that are stored for issue #11589. This can be "fixed" in 4.0 in the sense, that VCS filesystem will not scan file attributes, issue #11589 will probably become obsolete in 4.0.
While I was describibg the situation in a request for the waiver, I realized, that it has no sense to try to fix this. Conflicts in .nbattrs (even versioning of .nbattrs) is a pathological state. When .nbattrs files will become unusable a lof of things get broken. This has IMHO only one solution: The IDE must assure, that .nbattrs files will be usable. It's a question of who should do that, because this can happen as well on a local FS.
See issue #31308.
Is there a useful release note that I could provide for this problem? If so, could somebody suggest the text?
well, we'are after release of NB3.5 ... Are there any views of how to fix it, please? And or explanation why not? As Martin wrote it is pathological situation when ide has corrupted .nbattrs and lots of other stuffs could fail... thanks for answer
Scheduling for 4.0. This can be solved only when implementation of issue #11589 is removed. The issue #31056 might help here to find a suitable replacement, but it is possible that issue #11589 becomes obsolete in the new projects framework.
This was scheduled for 4.0 (promotion D). The only solution that can be implemented in VCS modules is, not to use the file object attributes. It's a question though, whether this really helps. Downgrading to P3. There were no complains about this from the users community, it happens rarely.
removing RELNOTE keyword as this doesn't seem to come up among users
Resolving as wontfix. There are no .nbattrs files created any more and the old are being cleared up.