0 Replies Latest reply on Nov 16, 2007 6:23 PM by Clint Popetz

    Slow integration test times with Embedded jboss

    Clint Popetz Apprentice

      I'm in the midst of transitioning a pretty large web app to use ejb3.0/seam. The app was in sort of a post-Struts1.2 state, i.e. several years of rolling our own internal framework to solve design problems until a decent web framework could come along.

      It seems like seam/jsf/ejb3.0 matches what we need pretty closely. Thanks so much for the work that went into this design. It's been dreamy replacing spring-based xml injection and hand-coded injection with @Name and @In.

      I made the design decision to make each action a seam component that is also a sfsb. They're all conversation scoped, though most never achieve long running conversation status. At this time we are also needing to convert to a cluster-aware 2nd level cache because our deployment has grown from 1 to 8 jboss instances running in a cluster, and the load on our database (of an unmentionable vendor) was just plain silly. This meant moving to using JTA, so that motivated making each action a session bean; then I got the transactions for free. (Well, free +/- two weeks of debugging.)

      So far so good, but the biggest hurdle has been the test suite, which is big. We have a _lot_ of integration tests, written with a strutsTestCase based home-grown framework that mocks requests, executes the actions, compiles jsps with jasper, executes them, and walks the html output checking for things.

      Now for why I'm posting: org.jboss.embedded.Bootstrap is slow. And seam startup is not speedy. It takes around 42 seconds to bootstrap everything. For automated continuous integration testing this is not a problem, but when writing an integration test it means tweak WAIT tweak WAIT...

      I modeled the bootstrapping off SeamTest and seam-gen's libs/paths. I'm guessing the issue is that I have around 180 session beans, most all of which are stateful. Here's the breakdown of time (numbers are in seconds)

      Bootstrap.deployResourceBases (28)
      EJBStage2Deployer.deploy (24.5)
      startPersistence units (7.8)
      buildSessionFactory (3.8)
      configure (4.0)
      build mappings (1.7)
      scanning for classes (1.1)
      parse hbms (1.0)
      registerEjbContainer: (15.5)
      EJBContainer.create (6.6)
      StatefulContainer.start (5.6)
      (almost all of that is addJaccContext and callees)
      AOPDependencyBuilder.getDependencies (2.8)
      Ejb3Deployment.processEJBContainerMetadata (1.0)
      EJBRegistrationDeployer.deploy (4.3)
      Bootstrap.bootstrap (5.6)
      DeploymentScanner.start (3.9)
      seam initialization (7.0)
      scan classes for components (3.5)
      parse ejb-jar.xml (0.5)
      look for all seam annotations in seam components (2.0)
      init spring (1.0) (<-- needed for one last spring dependency I can't chuck.)

      This is all on a P4 3.4GHz, 3GB RAM. The testng instance has been given a gig to work with, and isn't using it, so I'm not thrashing in GC.

      So I'm wondering...are other people seeing this? Is it misconfiguration? Are there ways to make it faster? We're trying to be extremely test-driven, but 40 seconds is just too long to wait in a test-writing cycle.

      Thanks for any help you can offer.