0 Replies Latest reply on Mar 20, 2009 5:29 AM by Martin Sparenberg

    Heap space exceeds during server start

    Martin Sparenberg Newbie

      Hello,
      we have a big web application (consisting of a lot of jsps, classes, ...) running greatly in Tomcat. For future extending to even more JEE-alike and making use of EJB3s, we are now planing to switch to JBoss-AS.
      On a local test deployment, we put our application (explodedly) into a JBoss (5.0) installation and tried to start it.
      The server bootstrap takes a long time and then crashes with

      09:41:20,104 INFO [NativeServerConfig] 3.0.4.SP1
      09:47:15,942 ERROR [ProfileServiceBootstrap] Failed to load profile:
      org.jboss.deployers.spi.DeploymentException: Error determining deployment structure for vfsfile:/data/home/[...]/de/bauen/bauthemen/baufinanzierung/ratgdl0014_copy/eig1/eig1_2/spar1.jsp
       at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)
       at org.jboss.deployers.plugins.main.MainDeployerImpl.addDeployment(MainDeployerImpl.java:322)
       [...]
      Caused by: java.lang.OutOfMemoryError: Java heap space
       at java.util.concurrent.CopyOnWriteArrayList.add(CopyOnWriteArrayList.java:366)
       at org.jboss.deployers.plugins.main.MainDeployerImpl.addContext(MainDeployerImpl.java:880)
       [...]

      Extra parameters for JVM are:
      export JAVA_OPTS="-Xms1024m -Xmx1024m -Dcom.sun.management.jmxremote"
      (tried also bigger and lower heap sizes. 4gb phys.ram available on a Centos-Linux system)

      When observing the memory usage with the jconsole tool, we see the "PS old gen" memory pool to overflow. When running the app in just Tomcat the "PS old gen" is also going up but very soon going down again.

      I made a file dump of the heap at error occurrance and looked into it using NetBeans-Profiler.
      ~49% of the heap space is occupied with instances of 'ConcurrentHashMap$Segmen', 'ConcurrentHashMap$HashEntry[]' and 'ReentrantLock$NonfairSync'.
      The most occurring non-JVM-classes are 'org.jboss.virtual.plugins.context.zip.ZipEntryContext$EntryInfo' (121343 instances) and 'org.jboss.virtual.plugins.context.zip.ZipEntryHandler' (121341 instances).
      When looking into some of the ZipEntryHandler instances we found in each a 'vsf-path'->'value' value naming one of our deployed resources (JSPs, classes, ...).

      It seems as the AS tries to build an internal representation (in a way tomcat doesn't?) that is getting too big for it to handle (?).

      Do you have further ideas on this issue or have experienced this phenomenon before and know a solution?

      Thanks in advance
      Martin