Bug 75967 - Out of memory when dealing with big wsdl files
Out of memory when dealing with big wsdl files
Status: RESOLVED FIXED
Product: webservices
Classification: Unclassified
Component: JAX-WS
6.x
All All
: P3 (vote)
: 7.4
Assigned To: Milan Kuchtiak
issues@webservices
: PERFORMANCE, RELNOTE
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-05-05 09:24 UTC by Lukas Jungmann
Modified: 2013-07-25 02:31 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
:


Attachments
JVM Options in Edit WS Attributes dialog (398.55 KB, image/png)
2013-07-11 08:07 UTC, Milan Kuchtiak
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lukas Jungmann 2006-05-05 09:24:01 UTC
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)
Comment 1 Milan Kuchtiak 2006-05-05 09:49:45 UTC
Any ideas how to deal with this ?
Comment 2 Lukas Jungmann 2006-05-05 10:05:29 UTC
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)
Comment 3 Martin Grebac 2006-05-05 12:02:53 UTC
Or check the size of the file in the dialog (or retriever) and show the warning.
Comment 4 Lukas Jungmann 2006-05-18 13:03:54 UTC
that would be enough for 5.5
Comment 5 Milan Kuchtiak 2006-09-05 15:32:32 UTC
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 ?
Comment 6 _ rkubacki 2006-09-06 08:13:48 UTC
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).
Comment 7 _ rkubacki 2006-09-06 09:19:58 UTC
You did not fix anything. Perhaps you intent to close this as wontfix?
Comment 8 Milan Kuchtiak 2006-09-06 09:24:50 UTC
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.
Comment 9 Martin Grebac 2006-09-06 17:57:25 UTC
 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.
Comment 10 _ rkubacki 2006-09-07 10:13:44 UTC
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?
Comment 11 Milan Kuchtiak 2006-09-07 16:56:46 UTC
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.
Comment 12 Lukas Jungmann 2007-10-17 00:12:41 UTC
v.
Comment 13 Sergey Grinev 2010-07-15 07:30:13 UTC
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.
Comment 14 Denis Anisimov 2011-10-07 06:31:03 UTC
It's a wsimport memory consumption problem.
It's related to the issue #168571.
Comment 15 Milan Kuchtiak 2013-07-11 08:02:16 UTC
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
Comment 16 Milan Kuchtiak 2013-07-11 08:07:05 UTC
Created attachment 136979 [details]
JVM Options in Edit WS Attributes dialog
Comment 17 Quality Engineering 2013-07-12 02:35:39 UTC
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
Comment 18 Quality Engineering 2013-07-25 02:31:07 UTC
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


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo