0 Replies Latest reply on Jun 2, 2011 12:24 AM by takach

    Very slow startup and response times when jars are in WAR/EAR

    takach

      Hi all,

       

      I try to port our app from JBoss4 to JBoss6. I also tried JBoss5 with success, but then I get the job to start with JBoss6. Our App is a simple WAR in an EAR, with 100+ Jars in WEB-INF/lib in WAR.

      Startup of JBoss6 without the App is ~40sec, with the App is ~8min. When I move the Jars to the lib folder of the JBoss instance, it starts in ~90sec, similarly to JBoss5 or JBoss4. Moreover, after the startup I have ~20-30sec response times, it looks like our Spring beans were very slow.

       

      I tried several workaround:

      - deploy only WAR

      - move the Jars to EAR/lib

      - setup of jboss-classloading in EAR, in WAR, in both

      - disable Annotation scanning

      but nothing helps. The only solution is when I move the Jars into the lib folder of the JBoss instance, but it is not a reasonable solution for us.

       

      When boot logging level is DEBUG, there is a significant 2-3min empty step in the log. For EAR the EarLibExcludeDeployer writes the last message. For WAR Deployment we have

       

      03:44:40,495 DEBUG [BeansDeploymentAopMetaDataDeployer] Finished deploying AbstractVFSDeploymentContext@335815472{vfs:///home/jboss6/server/template/deploy/xnio-provider.jar}

      03:46:50,807 DEBUG [OptAnnotationMetaDataDeployer] Deployment is metadata-complete, skipping annotation processing, ejbJarMetaData=null, jbossWebMetaData=org

      .jboss.metadata.web.spec.Web24MetaData@1f, jbossClientMetaData=null, bundleSymbolicName=null, metaDataCompleteIsDefault=false

      03:46:50,946 DEBUG [MergedJBossWebMetaDataDeployer] Resolved order: [ LIST OF OUR JARS ]
      03:46:50,955 DEBUG [MappedReferenceMetaDataResolverDeployer] vfs:///home/jboss6/server/template/deploy/my.war endpoint mappings:

      03:46:50,955 DEBUG [MappedReferenceMetaDataResolverDeployer] Processing unit=my.war, structure:
      my.war

          

      With TRACE level I can see that classloading activity is done during this period (also for EAR deployment). And also GenericAnnotationVisitor was active. At the end I could solve the Problem with the help of the patch https://issues.jboss.org/browse/JBAS-8786 and the jboss-scanning.xml of https://issues.jboss.org/browse/JBAS-7035 . At the analysis I used the followin command because the boot.log file was to big to easily navigate in:

      grep GenericAnnotationVisitor boot.log | more

       

      At the end I could apply the same solution for EAR Deployment, with jboss-scanning.xml in both WAR and containing EAR.