Publish maven project to Tomcat (via Servers) OutOfMemory Exceptions

[denlab]

Everytime I try to publish (or start) Tomcat within the Server's tool in STS (2.5.2, 2.6.1 SR1), I keep getting OutOfMemory Exceptions usually right when the container starts. here's my STS.ini:

-startup
plugins/org.eclipse.equinox.launcher_1.1.1.R36x_v20101122_1400.jar
--launcher.library
plugins/org.eclipse.equinox.launcher.win32.win32.x86_1.1.2.R36x_v20101222
-product
com.springsource.sts.ide
--launcher.defaultAction
openFile
--launcher.XXMaxPermSize
256M
-vmargs
-Dosgi.requiredJavaVersion=1.5
-Xms256m
-Xmx1024m
-XX:MaxPermSize=256m

Any ideas why tomcat throws those errors when starting under ecilpse?

[Martin Lippert]

Hi!

Do you see the OutOfMemory exception coming from the IDE you are working in (Error Log view in STS) or does it come from the Tomcat process you are starting? In case this is coming from the Tomcat process, you can set the VM options (-Xmx512m, for example) in the launch configuration for your server (Run... -> and choose the config for your server).

HTH,
Martin

[denlab]

Thanks Martin,

Exception is thrown by the IDE:

eclipse.buildId=2.5.2.201102261000-SR1
java.version=1.6.0_25
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
Framework arguments:  -product com.springsource.sts.ide
Command-line arguments:  -os win32 -ws win32 -arch x86 -product com.springsource.sts.ide


Error
Thu Jun 02 16:56:15 MDT 2011
An internal error occurred during: "Starting 211927-1".

java.lang.OutOfMemoryError
at java.util.zip.Inflater.inflateBytes(Native Method)
...

I set the VM Args of the Tomcat instance as you suggested:

-Xmx512m -Xss192k -XX:MaxPermSize=128m -Xms64m

And the error messages seem to have disappeared.

BTW, tomcat's never had problems starting outside the IDE (TC 6.0.32 win32), using the settings out of the box.

Thanks Again,
Denis

[Martin Lippert]

Hi Denis!

If the exception is thrown by the IDE, why is changing the Tomcat instance setting this behavior? This is strange... Can you post the complete stack trace? I really would like to see where this exception comes from. Maybe if there is a problem within the IDE, we should solve that... Thanks for your help!

Cheers,
-Martin

[denlab]

Acutally, spoke too soon, IDE still throwing OOM errors, whenever Server is Publishing, Validating, and even when it starts (after restarting the IDE).

Full stack

java.lang.OutOfMemoryError
at java.util.zip.Inflater.inflateBytes(Native Method)
at java.util.zip.Inflater.inflate(Inflater.java:238)
at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:135)
at java.io.BufferedInputStream.read1(BufferedInputStream.java:256)
at java.io.BufferedInputStream.read(BufferedInputStream.java:317)
at org.eclipse.jdt.internal.compiler.util.Util.getInputStreamAsByteArray(Util.java:323)
at org.eclipse.jdt.core.ToolFactory.createDefaultClassFileReader(ToolFactory.java:269)
at org.eclipse.jst.j2ee.internal.archive.JavaEEArchiveUtilities.isEJBArchive(JavaEEArchiveUtilities.java:885)
at org.eclipse.jst.j2ee.internal.archive.JavaEEArchiveUtilities.refineForJavaEE(JavaEEArchiveUtilities.java:591)
at org.eclipse.jst.j2ee.internal.archive.JavaEEArchiveUtilities.openArchive(JavaEEArchiveUtilities.java:370)
at org.eclipse.jst.j2ee.internal.archive.JavaEEArchiveUtilities.openBinaryArchive(JavaEEArchiveUtilities.java:290)
at org.eclipse.jst.j2ee.internal.componentcore.JavaEEBinaryComponentHelper$ArchiveCache.openArchive(JavaEEBinaryComponentHelper.java:601)
at org.eclipse.jst.j2ee.internal.componentcore.JavaEEBinaryComponentHelper.openArchive(JavaEEBinaryComponentHelper.java:459)
at org.eclipse.jst.j2ee.internal.componentcore.JavaEEBinaryComponentHelper.getUniqueArchive(JavaEEBinaryComponentHelper.java:411)
at org.eclipse.jst.j2ee.internal.componentcore.JavaEEBinaryComponentHelper.getArchive(JavaEEBinaryComponentHelper.java:404)
at org.eclipse.jst.j2ee.internal.componentcore.JavaEEBinaryComponentHelper.getJavaEEQuickPeek(JavaEEBinaryComponentHelper.java:87)
at org.eclipse.jst.j2ee.project.JavaEEProjectUtilities.getJ2EEComponentType(JavaEEProjectUtilities.java:273)
at org.eclipse.jst.j2ee.internal.common.exportmodel.JEEHeirarchyExportParticipant.isChildModule(JEEHeirarchyExportParticipant.java:68)
at org.eclipse.jst.common.internal.modulecore.SingleRootExportParticipant.shouldAddComponentFile(SingleRootExportParticipant.java:192)
at org.eclipse.jst.common.internal.modulecore.SingleRootExportParticipant.getMembers(SingleRootExportParticipant.java:140)
at org.eclipse.jst.common.internal.modulecore.SingleRootExportParticipant.getMembers(SingleRootExportParticipant.java:135)
at org.eclipse.jst.common.internal.modulecore.SingleRootExportParticipant.optimize(SingleRootExportParticipant.java:97)
at org.eclipse.wst.common.componentcore.internal.flat.FlatVirtualComponent.optimize(FlatVirtualComponent.java:145)
at org.eclipse.wst.common.componentcore.internal.flat.FlatVirtualComponent.cacheResources(FlatVirtualComponent.java:119)
at org.eclipse.wst.common.componentcore.internal.flat.FlatVirtualComponent.fetchResources(FlatVirtualComponent.java:101)
at org.eclipse.wst.web.internal.deployables.FlatComponentDeployable.members(FlatComponentDeployable.java:147)
at org.eclipse.wst.server.core.internal.ModulePublishInfo.fillCache(ModulePublishInfo.java:285)
at org.eclipse.wst.server.core.internal.ModulePublishInfo.getDelta(ModulePublishInfo.java:355)
at org.eclipse.wst.server.core.internal.ServerPublishInfo.getDelta(ServerPublishInfo.java:354)
at org.eclipse.wst.server.core.internal.Server.getPublishedResourceDelta(Server.java:1455)
at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.getPublishedResourceDelta(ServerBehaviourDelegate.java:699)
at org.eclipse.jst.server.tomcat.core.internal.TomcatServerBehaviour.getPublishedResourceDelta(TomcatServerBehaviour.java:958)
at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.computeDelta(ServerBehaviourDelegate.java:875)
at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:908)
at org.eclipse.wst.server.core.model.ServerBehaviourDelegate.publish(ServerBehaviourDelegate.java:775)
at org.eclipse.wst.server.core.internal.Server.publishImpl(Server.java:2893)
at org.eclipse.wst.server.core.internal.Server$PublishJob.run(Server.java:337)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

Session Data:

eclipse.buildId=2.5.2.201102261000-SR1
java.version=1.6.0_25
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_US
Framework arguments:  -product com.springsource.sts.ide
Command-line arguments:  -os win32 -ws win32 -arch x86 -product com.springsource.sts.ide

I've encountered this problem on 2.6.1.SR1 as well as 2.5.2.SR1 on a new pc work gave me (i5 w/ windohs xp 32bit), but never had this problem running on my old system (same os) using STS 2.3.2

2.6.1 works great (no problems at all) on my macbook, same projects

[Martin Lippert]

Can you check how much memory your IDE is actually consuming while it is running into this problem? Just wanna find out if it is indeed consuming too much memory or if the settings are not correct and the VM is running on a lower setting then we expect.

-Martin

[denlab]

Sorry for the late reply, the weekend was so nice, I thought I might just extend it

IDE consumes roughly 250 MB on startup, and when tc starts jumps to 325-350. The error happens as soon as tc starts, or when synchronizing (server->clean), or when it "validates", however the console continues to chug away, and tc loads the contexts, and the app is deployed to the container. When I shutdown the server, there is no change in mem consumption (should there be a drop?).

I should point out that for some reason, one of our project's maven module (webapp dependency) application-context files does not get packaged & subsequently deployed, and tc complains about it (it's the app context with our session factory). Doing a build outside of the IDE works perfectly. The same projects deploy successfully from within the IDE on my macbook (straight out of SVN). I just assume this is an environment specific issue, though I've no idea why that specific project's context doesn't get deployed, when all others do...

[dlmiles]

Corrupted JAR ? You are OOM in a native method. Are native methods even memory restricted (other than OS limits) ? This is probably a bug in the decompressor for not checking the values it sees are sane (when trying to parse a header, it sees it need to allocate some huge size and tried to malloc it).