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.
When trying to open a large XML file (in my case 12MB) the parser stops with an "Internal parser error". I guess it's due to memory restrictions (the VM for NetBeans is limited to 180MB). It would nice if it was possible to open files like that.
Thanks for quick response. If it is possible could you attached zipped the XML file? We could test it on real document -- our test documents can differ by element deep level, number of attributes, etc. Thanks.
I'm sorry but the file is catalog file with detailed information about products and prices of one of our customers, and I'm not allowed to pass that on to third parties...
OK, I will try docbook files mentioned in issue #22152.
It is general problem when you want to load/parse big document into object structure and keep it in memmory. It needs too big changes in tree structure what is long-term work. I suggest to mark it is FFJ 4.0 waiver.
FFJ 4.0 waiver approved.
Thomas could you please attach the exception? Memory restrictions should produce OutOfMemoryError instead of the "Internal parser error". Anyway large documents often produces OutOfMemoryError. It can be solved by utilizing MDR with its disk swapping feature.
*** Issue 22206 has been marked as a duplicate of this issue. ***
*** Issue 22163 has been marked as a duplicate of this issue. ***
Target milestone was changed from not determined to TBD
If this is known to happen for some files, probably a candidate for the release notes.
It's mentioned directly in the docs (Editing an XML Document). Should it go into the release notes as well?
This bug is reported in version <= 3.4dev and still not fixed. Due to that it forbids the release candidate for 3.4 to be promoted. Are you aware of that and are you intensively working on the fix? If not, you should consider some corrective action.
XML model (TAX) is not designed for large document -- then I could say it is as designed behaviour, however I do not agree with it. John mentioned that it is described in XML documentation and maybe it should be mentioned in release notes too. Other work on TAX was for 3.4 postponed, large files tree editing is not our strategic feature. One important was fixed: referenced TAX instances are correctly weak - not used references can be released by GC.
We estimated that proper fix implementation requires 3 developer/weeks (rewrote parser and introduce positions). Based on this estime the strategy commite marked XML performance as non strategic issue for Sun's contribution to NetBeans. From Sun's point of view it was classified as nice to have enhancement. From user's point of view it is a bug. I do not know how to express this state using IZ.
3.4_WAIVER: architecture changes are necessary (no simple fix is possible).
proposed release note (combined with note for 22152): Large and complex XML files open very slowly in the tree editor and might cause OutOfMemory errors. Workaround: Open such files with the Edit command to edit them in the text editor instead of the tree editor.
I agree with waiver for 3.4
I agree with 3.4 waiver; leaving my name on CC for relnote purposes
Could this just be marked dupe of issue #22152, or vice-versa?
I agree with it. If nobody objects I will mark this as duplicate of issue 22152 (which already contains discussion about possible solution).
Version was changed on 'S1S 4.2'.
S1S5_WAV request justification: It is general problem when you want to load/parse big document into object structure and keep it in memmory. It needs too big changes in tree structure what is long-term work. I suggest to postpone it until common. Estimated fix: Not decided, depends on MDR or equalent availability
Reopening. Please don't use the RESOLVED LATER status flag. There is no common agreement on its meaning. In reality, the issue is not RESOLVED, is it?
LATER means that I cannot fix it under current contraints. Transitively this issue is known contraint/limitation of current implementation. LATER is optimistics alternative to WONTFIX.
I'm working on fix for Generate DTD action. Removing TAX dependency in this action implementation will further minimize the problem occurency probability.
<-- GuiUtil.java new revision: 1.4.2.1; previous revision: 1.4 <-- Bundle.properties new revision: 1.18.4.1; previous revision: 1.18 <-- GenerateDTDSupport.java new revision: 1.14.2.1; previous revision: 1.14 Generate DTD action made more lightweight. Now it creates tiny memory structure containing only statistical data instead of huge model of whole source XML document.
Marking as FIXED in reduced set of client modules (excluding Visual XML editor). I scanned the reduced set and found only usage of TAX DTD models. I have never seen DTD bigger that 1Mb. TAX XML models are now utilized only in Visual XML editor and I filled issue #31656 to address it separately.
VERIFIED
removing RELNOTE keyword
what kind of forum is this? not giving any kind of solution for our problem???? we are working on the same problem since a week and still not getting the problem.. we get the error of "outofmemory"... the first worst thing about netbeans is that it takes eons to startup its modules and then works too slow giving errors of out of memory... we have a 2GB RAM with 360GB hard disk and still the same problem... do we have to buy a super computer and make netbeans work on it?? we are plannin to change the IDE if the same problem persists... netbeans is really the worst IDE... sorry, but before changing the IDE would like to have a solution to memory problem if you can suggest
Was spuriously reopened.