When one works with big wsld files (don't know the limit but wsdl for e-bay
websvc is big enough - ~2,3MB) ide ends up with OutOfMemoryError and becomes
unusable for a while - it can occur durring creation of ws client or ws from wsdl.
Workaround for this is to edit "-J-Xmx128m" starup parameter in
$NB_HOME/etc/netbeans.conf (changing it to "-J-Xmx256m" seems to be enough)
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 -r18.104.22.168.2.3 -r22.214.171.124.2.2
< # if you're processing large wsdl files(e.g. when creating or consuming web
services) you should set -J-Xmx256m instead of -J-Xmx128m
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
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
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.
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
java.lang.OutOfMemoryError: Java heap space
at sun.reflect.GeneratedMethodAccessor49.invoke(Unknown Source)
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)
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)
User: Milan Kuchtiak <firstname.lastname@example.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)
User: Milan Kuchtiak <email@example.com>
Log: #75967 improve the layout of JVM Options text field description