Any ideas how to deal with this ?

I have 3 ideas:

-mention it in relnotes - done for now

-put some comment to $NB_HOME/etc/netbeans.conf - something like "if you're
working with big wsdl files then you should set -J-Xmx256m instead of -J-Xmx128m"

-make -J-Xmx256m option default in netbeans.conf - would be probably the best,
because other parts of the IDE could benefit from this, BUT this would have an
impact on the minimum hardware configuration the IDE can be run on (at least
this is what I've heart from a guy from performance team)

Or check the size of the file in the dialog (or retriever) and show the warning.

that would be enough for 5.5

Meanwhile, I put the comment to netbeans.conf :

diff -r1.17.8.4.2.3 -r1.17.8.4.2.2
13,14d12
< #
< # if you're processing large wsdl files(e.g. when creating or consuming web
services) you should set -J-Xmx256m instead of -J-Xmx128m



Guys,
could it be possible to start Netbeans5.5 defaultly with -J-Xmx256m ?

Did anyone try to analyze why it actually needs so much memory?

-1 to increase default max heap size. So far there is no reasonable
justification why this is really neceseary.

I can come with many examples where our IDE needs higher -Xmx than default so
mentioning this one special case in netbeans.conf is not too good approach IMO.
Section in release notes can be fine.

Implementation of Martin's idea is likely to be fragile (it is clear how large
part of heap can be used for your task and you have to have some estimation what
you will need).

You did not fix anything. Perhaps you intent to close this as wontfix?

2 of three ideas were implemented so the FIXED was proper word.

The real measurement was not provided.
There are real wsdl files that results in OutOfMemoryError.

It's difficult to implement Martin's idea:
- there are usually more files than one wsdl.
- the memmory consumption may depend not only on wsdl size.

We are not able to improve the memmory consumtion since we use internal JAX-WS
classes (the same as wsimport utility) to generate model for wsdl file.

 Well, we should certainly try to measure and find the problem. If we are not
able to fix it, I still don't understand why would a threshold (has to be
measured, but, let's say 500kb-1MB) triggering a warning about potential problem
and explaining the fix (-Xmx) be a bad and fragile idea. I think we would really
catch the ebay wsdl problem.

No Milan. You did not fix anything. We only provided a hint about existing
workaround.

Who is responsible for JAX-WS? Did we report this problem? Are we sure this 3rd
party ocmponent is the only reason? Can't we help to reduce its memory demands?

JAX-WS team made some memory consumption improvements in jax-ws2.0.1
We still use jax-ws2.0. The jax-ws2.0.1 hasn't been tested with Netbeans yet.
We need to be synchronized with JAX-WS used in GlassFish and as far as I know
they use JAX-WS2.0

See:
http://forums.java.net/jive/thread.jspa?messageID=140472 

However, jax-ws generates bunch of classes. The larger schemas are used, the
more java files are generated. Those could be hundreds, may be thousands.
So that could be also problem with MDR.

Radim, could you help us with heap measurement.

v.

Reproducible in NB6.9 and there is no information about workaround not in Release Notes (http://netbeans.org/community/releases/69/relnotes.html) nor in /etc/netbeans.conf

<...>\nbproject\jaxws-build.xml:24: 
java.lang.OutOfMemoryError: Java heap space
        at java.util.HashMap.<init>(HashMap.java:209)
        at com.sun.codemodel.JDocComment.<init>(JDocComment.java:58)
        at com.sun.codemodel.JMethod.javadoc(JMethod.java:389)
        at com.sun.tools.xjc.generator.bean.ImplStructureStrategy$1$1.javadoc(ImplStructureStrategy.java:109)
        at com.sun.tools.xjc.generator.bean.field.UntypedListField.generateAccessors(UntypedListField.java:124)
        at com.sun.tools.xjc.generator.bean.field.AbstractListField.generate(AbstractListField.java:127)
        at com.sun.tools.xjc.generator.bean.field.UntypedListField.<init>(UntypedListField.java:107)
        at com.sun.tools.xjc.generator.bean.field.UntypedListFieldRenderer.generate(UntypedListFieldRenderer.java:72)
        at com.sun.tools.xjc.generator.bean.field.DefaultFieldRenderer.generate(DefaultFieldRenderer.java:79)
        at com.sun.tools.xjc.generator.bean.BeanGenerator.generateFieldDecl(BeanGenerator.java:747)
        at com.sun.tools.xjc.generator.bean.BeanGenerator.generateClassBody(BeanGenerator.java:535)
        at com.sun.tools.xjc.generator.bean.BeanGenerator.<init>(BeanGenerator.java:235)
        at com.sun.tools.xjc.generator.bean.BeanGenerator.generate(BeanGenerator.java:175)
        at com.sun.tools.xjc.model.Model.generateCode(Model.java:286)
        at com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImpl.java:252)
        at com.sun.tools.xjc.api.impl.s2j.SchemaCompilerImpl.bind(SchemaCompilerImpl.java:85)
        at com.sun.tools.ws.processor.modeler.wsdl.JAXBModelBuilder.bind(JAXBModelBuilder.java:134)
        at com.sun.tools.ws.processor.modeler.wsdl.WSDLModeler.buildJAXBModel(WSDLModeler.java:2264)
        at com.sun.tools.ws.processor.modeler.wsdl.WSDLModeler.internalBuildModel(WSDLModeler.java:187)
        at com.sun.tools.ws.processor.modeler.wsdl.WSDLModeler.buildModel(WSDLModeler.java:133)
        at com.sun.tools.ws.wscompile.WsimportTool.run(WsimportTool.java:185)
        at com.sun.tools.ws.ant.WsImport2.execute(WsImport2.java:689)
        at com.sun.istack.tools.ProtectedTask.execute(ProtectedTask.java:55)
        at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
        at sun.reflect.GeneratedMethodAccessor49.invoke(Unknown Source)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
        at org.apache.tools.ant.Task.perform(Task.java:348)
        at org.apache.tools.ant.Target.execute(Target.java:390)
        at org.apache.tools.ant.Target.performTasks(Target.java:411)
        at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1360)


P.S.: Workaround helps although: I had to setup -Xmx512m in order to get wsimport working.

It's a wsimport memory consumption problem.
It's related to the issue #168571.

Added a new "JVM Options" text field for wsimport, in Web Service (WS Reference) -> Edit WS Attributes -> Wsimport Options section.

This option allows to increase the heap size for wsimport task JVM (needs also to specify fork=true in the same dialog).

Thus the (ant)build script, running in the same JVM as Netbeans, will not consume Netbeans memory when wsimport task is executed.

In case Netbeans itself ends with OutOfMemoryError, increasing the heap size for Netebans JVM is needed (in NB_HOME/etc/netbeans.conf)

See:
http://hg.netbeans.org/web-main/rev/a30977f027ac

Created attachment 136979 [details]
JVM Options in Edit WS Attributes dialog

Integrated into 'main-silver', will be available in build *201307112300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/a30977f027ac
User: Milan Kuchtiak <mkuchtiak@netbeans.org>
Log: #75967 add wsimport JVM Options text field to WS Customizer

Integrated into 'main-silver', will be available in build *201307242300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/0e2810a94f5b
User: Milan Kuchtiak <mkuchtiak@netbeans.org>
Log: #75967 improve the layout of JVM Options text field description