Grails

Two differently named instances of Grails WAR file deployed to Tomcat; crashes Tomcat

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Not A Bug
  • Affects Version/s: 1.2 final
  • Fix Version/s: 1.2.1
  • Component/s: None
  • Labels:
    None
  • Environment:
    Tested on Mac and Linux, Tomcat 5.5 and 6, JRE 5 and 6.

Description

Create a very simple project with Grails, and build a WAR file:

> grails create-app simple
> grails create-controller test
> grails war

Deploy to Tomcat:

> cp target/simple-0.1.war /opt/tomcat/webapps/simple.war

Works Ok ... deploy a copy of the same WAR but different name:

> cp target/simple-0.1.war /opt/tomcat/webapps/crash-me.war

Crashes, with log attached below. This pretty much brings down Tomcat in fact, and it seems only removing "simple.war" or "crash-me.war" and restarting Tomcat seem to really bring things back.

This seems a dangerously simple way to being down Tomcat with Grails. Any ideas why and how to avoid?

Thanks!

==================================================================================================
INFO: Deploying web application archive crash-me.war
2010-01-19 20:31:11,742 [ContainerBackgroundProcessor[StandardEngine[Catalina]]] ERROR context.ContextLoader - Context initialization failed
org.springframework.beans.factory.access.BootstrapException: Error executing bootstraps; nested exception is org.codehaus.groovy.runtime.InvokerInvocationException: java.lang.OutOfMemoryError: PermGen space
at org.codehaus.groovy.grails.web.context.GrailsContextLoader.createWebApplicationContext(GrailsContextLoader.java:74)
at org.springframework.web.context.ContextLoader.initWebApplicationContext(ContextLoader.java:192)
at org.springframework.web.context.ContextLoaderListener.contextInitialized(ContextLoaderListener.java:47)
at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:3934)
at org.apache.catalina.core.StandardContext.start(StandardContext.java:4429)
at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791)
at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526)
at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:850)
at org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:724)
at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:493)
at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1274)
at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119)
at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1337)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1601)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1610)
at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1590)
at java.lang.Thread.run(Thread.java:619)
Caused by: org.codehaus.groovy.runtime.InvokerInvocationException: java.lang.OutOfMemoryError: PermGen space
at grails.spring.BeanBuilder.invokeBeanDefiningClosure(BeanBuilder.java:720)
at grails.spring.BeanBuilder.beans(BeanBuilder.java:570)
at grails.spring.BeanBuilder.invokeMethod(BeanBuilder.java:516)
... 1 more
Caused by: java.lang.OutOfMemoryError: PermGen space
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
Jan 19, 2010 8:31:11 PM org.apache.catalina.core.StandardContext start
SEVERE: Error listenerStart
Jan 19, 2010 8:31:11 PM org.apache.catalina.core.StandardContext start
SEVERE: Context [/crash-me] startup failed due to previous errors

java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
Caused by: java.lang.OutOfMemoryError: PermGen space

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Graeme Rocher added a comment -

You should assign more permgen, the defaults are probably not enough:

-XX:PermSize=256m -XX:MaxPermSize=512m

Show
Graeme Rocher added a comment - You should assign more permgen, the defaults are probably not enough: -XX:PermSize=256m -XX:MaxPermSize=512m
Hide
Permalink
Aaron Harder added a comment -

Yes, that fixed it! At least on Linux. Will test on Mac as well (where I thought I had already attempted a CATALINA_OPTS tuning of this type).

Thanks very much for the quick reply.

Show
Aaron Harder added a comment - Yes, that fixed it! At least on Linux. Will test on Mac as well (where I thought I had already attempted a CATALINA_OPTS tuning of this type). Thanks very much for the quick reply.
Hide
Permalink
Aaron Harder added a comment -

Changing MaxPermSize to 512m did also fix this issue on Mac. (I had previously changed the MaxPermSize setting, but hadn't bumped it as high as 512m.)

I would still say that it might be worth investigating the reported issue: I can have two or more different grails apps co-existing happily as WAR files on a default Tomcat install. But when I deploy just two instances of the same app but with different WAR names (even the VERY simple app shown in my example) it will bring Tomcat to its knees.

Definitely a gotchya for new users. Also this seems an unexpected resource drain on Tomcat being caused by something unknown and probably unintended. It might be worth chasing down the root cause. Glad to help do so if I can.

Thanks again for your help!

Show
Aaron Harder added a comment - Changing MaxPermSize to 512m did also fix this issue on Mac. (I had previously changed the MaxPermSize setting, but hadn't bumped it as high as 512m.) I would still say that it might be worth investigating the reported issue: I can have two or more different grails apps co-existing happily as WAR files on a default Tomcat install. But when I deploy just two instances of the same app but with different WAR names (even the VERY simple app shown in my example) it will bring Tomcat to its knees. Definitely a gotchya for new users. Also this seems an unexpected resource drain on Tomcat being caused by something unknown and probably unintended. It might be worth chasing down the root cause. Glad to help do so if I can. Thanks again for your help!
Hide
Permalink
Richa khandelwal added a comment -

Aaron I am running into exact same issue, i increased the MaxPermSize to 1560 M but still getting out of memory error which goes away on page refresh. I was wondering if you found any solution to this problem?

Show
Richa khandelwal added a comment - Aaron I am running into exact same issue, i increased the MaxPermSize to 1560 M but still getting out of memory error which goes away on page refresh. I was wondering if you found any solution to this problem?

People

Vote (0)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.1#660-r161644) | Report a problem
Powered by a free Atlassian JIRA open source license for Grails project. Try JIRA - bug tracking software for your team.