Forum Discussion

bitbot's avatar
bitbot
Occasional Contributor
15 years ago

Java heap space error, already at limit of 32-bit JVM?

Hello,
I'm using SoapUI Pro 3.6.1, with Java 1.6.0_23, on a Windows 7 x86 machine. My soapui-pro.bat file contains the following line, which I understood to be the max values for a 32 bit JVM:

set JAVA_OPTS=-Xms128m -Xmx1400m -Dsoapui.properties=soapui.properties -Dgroovy.source.encoding=iso-8859-1 "-Dsoapui.home=%SOAPUI_HOME%\"

I'm seeing java heap space errors when running tests driven by extensive data sets, using an OracleThin/oracle.jdbc.driver.OracleDriver (ojdbc14-10.2.0.4.jar) to fetch the data into DataSources.

In general, during testing, I can watch SoapUI climb from ~210 MB of memory in use when the application is opened, to 1.3 GB of memory in use throughout a day of testing. When it starts to reach 1.3 and 1.4 GB, the UI becomes slow and frequently non-responsive (UI updates are replaced by a black screen), and eventually tests will die throwing a java heap space error.

I can clear the condition by quitting SoapUI (when I can force the UI to do so) and reopening it.

Is this the sign of a memory leak? It doesn't seem right to watch the memory footprint increase so dramatically when tests should be completed and then freed from memory. Can you help me understand what I might be able to do to resolve these problems?

I am trying to secure a 64-bit machine on which to do some testing to see if the problem can at least be masked by having a larger memory pool, but my manager and IT department won't let me pursue this without first posting this problem report on your forum. Thanks for any help you can provide.

Bitbot

10 Replies

  • Hi,

    Hmm... Not sure what is causing this. There is something you could do which would help us a lot. First, you will need the Java JDK installed, which you can get from here if you do not already have it installed: http://www.oracle.com/technetwork/java/javase/downloads/index.html. Once downloaded, run soapUI as you normally would until you notice that it is using a lot of memory and is slugish (but before it dies). Then locate the jvisualvm.exe file which should be in the bin directory of the JDK installation. Double-click it to start it, and then double-click on the soapUI process in the Applications tree (it may come up as <Unknown Application>). Now switch to the "Monitor" tab, and press the button which says "Heap Dump". This should create a child node under the main one in the Applications tree. Right click that node and select "Save as" and save the file. It may be a pretty large file (almost 100MB), so you may not be able to mail it to us, but if you're willing to try this we can set up an FTP server or something so that you can transfer the file to us. It should help us diagnose what the problem is.

    Regards,
    Dain
    eviware.com
  • Hi!

    just a quick addition: before you create the dump, please close all your projects in soapUI and make sure to run the Garbage Collector at least once (available via right-click on the memory log), so only objects that are not being released correctly are left on the heap.

    (you could create one dump before and one after this.. )

    Thanks for your efforts in any case!

    regards,

    /Ole
    eviware.com
  • bitbot's avatar
    bitbot
    Occasional Contributor
    I was able to get a full heap dump (before Garbage Collection) on my x86 machine. It weighs in at ~1.2gb. When I tried to run Garbage Collection, the UI was non responsive so I wasn't able to make it happen or grab it.

    I was finally given the x64 machine to see if this resolves the problem. While it appears to have resolved the acute problem (no Java heap space errors yet), it does reach a point around 1.3 or 1.4gb of memory used where performance slows down significantly, with each query/test taking roughly 5-20x longer to complete that usual. This time, I was able to stop the test, close my projects, run garbage collection, and do a heap dump. It weighs in at 922mb.

    I don't have an FTP to host these on, so I guess I will upload them to some cloud storage and PM you the links. If Eviware could host an FTP on which users could upload heap dumps, that could be helpful and would be appreciated =]
  • bitbot's avatar
    bitbot
    Occasional Contributor
    I have HTTP links to the heap dumps now, but I can't seem to PM 'eviware support'. How can I get you the links? I would prefer not to post the URL publicly.
  • bitbot's avatar
    bitbot
    Occasional Contributor
    Here are the errors I'm receiving in the error log:

    Thu May 05 22:14:56 CDT 2011:ERROR:java.lang.OutOfMemoryError: GC overhead limit exceeded java.lang.OutOfMemoryError: GC overhead limit exceeded at java.util.HashSet.<init>(Unknown Source) at org.codehaus.groovy.reflection.CachedClass$8.initValue(CachedClass.java:191) at org.codehaus.groovy.reflection.CachedClass$8.initValue(CachedClass.java:189) at org.codehaus.groovy.util.LazyReference.getLocked(LazyReference.java:46) at org.codehaus.groovy.util.LazyReference.get(LazyReference.java:33) at org.codehaus.groovy.reflection.CachedClass.getInterfaces(CachedClass.java:241) at org.codehaus.groovy.reflection.CachedClass.<init>(CachedClass.java:227) at org.codehaus.groovy.reflection.ClassInfo.createCachedClass(ClassInfo.java:249) at org.codehaus.groovy.reflection.ClassInfo.access$400(ClassInfo.java:36) at org.codehaus.groovy.reflection.ClassInfo$LazyCachedClassRef.initValue(ClassInfo.java:425) at org.codehaus.groovy.reflection.ClassInfo$LazyCachedClassRef.initValue(ClassInfo.java:416) at org.codehaus.groovy.util.LazyReference.getLocked(LazyReference.java:46) at org.codehaus.groovy.util.LazyReference.get(LazyReference.java:37) at org.codehaus.groovy.reflection.ClassInfo.getCachedClass(ClassInfo.java:89) at org.codehaus.groovy.reflection.ReflectionCache.getCachedClass(ReflectionCache.java:107) at org.codehaus.groovy.classgen.BytecodeHelper.box(BytecodeHelper.java:91) at org.codehaus.groovy.runtime.callsite.CallSiteGenerator.writeMethod(CallSiteGenerator.java:98) at org.codehaus.groovy.runtime.callsite.CallSiteGenerator.genCallXxxWithArray(CallSiteGenerator.java:141) at org.codehaus.groovy.runtime.callsite.CallSiteGenerator.genPojoMetaMethodSite(CallSiteGenerator.java:183) at org.codehaus.groovy.runtime.callsite.CallSiteGenerator.compilePojoMethod(CallSiteGenerator.java:225) at org.codehaus.groovy.reflection.CachedMethod.createPojoMetaMethodSite(CachedMethod.java:244) at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.createCachedMethodSite(PojoMetaMethodSite.java:158) at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.createPojoMetaMethodSite(PojoMetaMethodSite.java:147) at groovy.lang.MetaClassImpl.createPojoCallSite(MetaClassImpl.java:3003) at org.codehaus.groovy.runtime.callsite.CallSiteArray.createPojoSite(CallSiteArray.java:114) at org.codehaus.groovy.runtime.callsite.CallSiteArray.createCallSite(CallSiteArray.java:148) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:40) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:124) at aws.restservices.CompareResponseData.pseudoBooleanCompare(aws.restservices.CompareResponseData:93) at aws.restservices.CompareResponseData$pseudoBooleanCompare.call(Unknown Source) at Script1.run(Script1.groovy:63) Thu May 05 22:17:20 CDT 2011:ERROR:java.lang.OutOfMemoryError: GC overhead limit exceeded java.lang.OutOfMemoryError: GC overhead limit exceeded at groovyjarjarasm.asm.ClassWriter.newUTF8(Unknown Source) at groovyjarjarasm.asm.ClassWriter.a(Unknown Source) at groovyjarjarasm.asm.ClassWriter.newClass(Unknown Source) at groovyjarjarasm.asm.ClassWriter.a(Unknown Source) at groovyjarjarasm.asm.MethodWriter.visitMethodInsn(Unknown Source) at org.codehaus.groovy.runtime.callsite.CallSiteGenerator.writeMethod(CallSiteGenerator.java:112) at org.codehaus.groovy.runtime.callsite.CallSiteGenerator.genCallXxxWithArray(CallSiteGenerator.java:141) at org.codehaus.groovy.runtime.callsite.CallSiteGenerator.genPojoMetaMethodSite(CallSiteGenerator.java:183) at org.codehaus.groovy.runtime.callsite.CallSiteGenerator.compilePojoMethod(CallSiteGenerator.java:225) at org.codehaus.groovy.reflection.CachedMethod.createPojoMetaMethodSite(CachedMethod.java:244) at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.createCachedMethodSite(PojoMetaMethodSite.java:158) at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.createPojoMetaMethodSite(PojoMetaMethodSite.java:147) at groovy.lang.MetaClassImpl.createPojoCallSite(MetaClassImpl.java:3003) at org.codehaus.groovy.runtime.callsite.CallSiteArray.createPojoSite(CallSiteArray.java:114) at org.codehaus.groovy.runtime.callsite.CallSiteArray.createCallSite(CallSiteArray.java:148) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:40) at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:54) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:124) at org.codehaus.groovy.ast.builder.AstBuilderInvocationTrap.visitMethodCallExpression(AstBuilderTransformation.groovy:192) at org.codehaus.groovy.ast.expr.MethodCallExpression.visit(MethodCallExpression.java:72) at org.codehaus.groovy.ast.CodeVisitorSupport.visitExpressionStatement(CodeVisitorSupport.java:69) at org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:40) at org.codehaus.groovy.ast.CodeVisitorSupport.visitBlockStatement(CodeVisitorSupport.java:35) at org.codehaus.groovy.ast.stmt.BlockStatement.visit(BlockStatement.java:51) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoCachedMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:229) at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:52) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:40) at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:54) Thu May 05 22:37:49 CDT 2011:ERROR:java.lang.OutOfMemoryError: GC overhead limit exceeded java.lang.OutOfMemoryError: GC overhead limit exceeded Thu May 05 22:38:09 CDT 2011:ERROR:java.lang.OutOfMemoryError: GC overhead limit exceeded java.lang.OutOfMemoryError: GC overhead limit exceeded Thu May 05 22:38:20 CDT 2011:ERROR:java.lang.OutOfMemoryError: GC overhead limit exceeded java.lang.OutOfMemoryError: GC overhead limit exceeded Thu May 05 22:38:48 CDT 2011:ERROR:java.lang.OutOfMemoryError: GC overhead limit exceeded java.lang.OutOfMemoryError: GC overhead limit exceeded Thu May 05 22:39:09 CDT 2011:ERROR:java.lang.OutOfMemoryError: GC overhead limit exceeded Thu May 05 22:39:57 CDT 2011:ERROR:java.lang.OutOfMemoryError: GC overhead limit exceeded java.lang.OutOfMemoryError: GC overhead limit exceeded Thu May 05 22:40:02 CDT 2011:ERROR:java.lang.OutOfMemoryError: GC overhead limit exceeded java.lang.OutOfMemoryError: GC overhead limit exceeded Thu May 05 22:40:40 CDT 2011:ERROR:java.lang.OutOfMemoryError: GC overhead limit exceeded java.lang.OutOfMemoryError: GC overhead limit exceeded Thu May 05 22:40:45 CDT 2011:ERROR:java.lang.OutOfMemoryError: GC overhead limit exceeded java.lang.OutOfMemoryError: GC overhead limit exceeded Thu May 05 22:41:45 CDT 2011:ERROR:java.lang.OutOfMemoryError: GC overhead limit exceeded java.lang.OutOfMemoryError: GC overhead limit exceeded Thu May 05 22:42:09 CDT 2011:ERROR:java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError: GC overhead limit exceeded java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError: GC overhead limit exceeded at java.util.concurrent.FutureTask$Sync.innerGet(Unknown Source) at java.util.concurrent.FutureTask.get(Unknown Source) at com.eviware.soapui.impl.wsdl.support.AbstractTestRunner.waitUntilFinished(AbstractTestRunner.java:221) at com.eviware.soapui.impl.wsdl.testcase.WsdlProjectRunner.runTestSuite(WsdlProjectRunner.java:168) at com.eviware.soapui.impl.wsdl.testcase.WsdlProjectRunner.runSequential(WsdlProjectRunner.java:138) at com.eviware.soapui.impl.wsdl.testcase.WsdlProjectRunner.internalRun(WsdlProjectRunner.java:93) at com.eviware.soapui.impl.wsdl.testcase.WsdlProjectRunner.internalRun(WsdlProjectRunner.java:36) at com.eviware.soapui.impl.wsdl.support.AbstractTestRunner.run(AbstractTestRunner.java:135) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded Thu May 05 22:42:23 CDT 2011:ERROR:java.lang.OutOfMemoryError: GC overhead limit exceeded java.lang.OutOfMemoryError: GC overhead limit exceeded Fri May 06 10:18:44 CDT 2011:ERROR:java.lang.OutOfMemoryError: GC overhead limit exceeded java.lang.OutOfMemoryError: GC overhead limit exceeded


    Here is the current line in my soapui-pro.bat:

    set JAVA_OPTS=-Xms512m -Xmx4096m -Dsoapui.properties=soapui.properties -Dgroovy.source.encoding=iso-8859-1 "-Dsoapui.home=%SOAPUI_HOME%\"


    This machine has 8gb of physical RAM.
  • bitbot's avatar
    bitbot
    Occasional Contributor
    After doing a lot of SOAP testing today and not experiencing any of the above behaviors, I'm starting to believe these problems are exclusive to REST test requests. We're using identical data structures and loops in the validation steps on the SOAP side of things, but those tests don't seem to be affected by the gradual ramp-up in the memory log.

    I'll fire off some heap dump links to the email you provided. Screenshots of memory log behavior on REST vs. SOAP are probably next. Thanks for your help.
  • Westpac_Banking's avatar
    Westpac_Banking
    Occasional Contributor
    Hi,

    I am getting the below error while importing the wsdl.
    soapUI log:
    Thu Nov 10 11:24:52 EST 2011:ERROR:An error occured [Java heap space], see error log for details
    soapui-errors.log:
    2011-11-10 11:24:53,229 ERROR [errorlog] java.lang.OutOfMemoryError: Java heap space
    java.lang.OutOfMemoryError: Java heap space
    at java.util.ArrayList.<init>(Unknown Source)
    at java.util.ArrayList.<init>(Unknown Source)
    at com.eviware.soapui.support.types.StringList.<init>(StringList.java:28)
    at com.eviware.soapui.support.scripting.groovy.SoapUIGroovyClassLoader.syncExternalClasses(SourceFile:100)
    at com.eviware.soapui.support.scripting.groovy.SoapUIGroovyClassLoader.run(SourceFile:80)
    at java.lang.Thread.run(Unknown Source)

    Please suggest me the solution.
  • Westpac_Banking's avatar
    Westpac_Banking
    Occasional Contributor
    Hi,

    I have mailed the xsd's and wsdl from the mail id Shweta Samvedi.
    wsdl and xsd's are official and so please keep maintain the privacy.

    Regards,
    Udhaya