1 Reply Latest reply on Feb 17, 2002 3:43 PM by David Jencks

    Performance drop using self-contained jars?

    Chris Harris Newbie

      (sorry for the title - can't think of a snappy way to describe the problem).

      Situation: JBoss 2.4.3, Win2k, Sun JDK 1.3.1.

      We are developing a large spftware suite which uses lots of beans and has a lot of inter-bean communication. This suite is split into roughly 15 modules, each one is an EJB jar (and therefore a J2EE 'application') in its own right and is deeloyed to jboss separately.

      Since there is some cross-application communication we also build client jars (containing remote interfaces, value object classes and other utilities) and use these when compiling the other modules and also when running test cases (which are all external to the server). So, nothing special so far.

      Our original configuration had an extra classpatheextension in jboss.conf pointing to the directory containing all these client jars. Each application jar was then able to pick up the interface classes it needed since they would be available to all applications within JBoss. The downside of this is of course that in development we lose hot-deploy ability since jboss locks the client jars and the build process needs to update them. The other downside is that developers are given more freedom to add inter-module dependencies since all the beans are available for them to use.

      So I changed the configuration of jboss to completely encapsulate each of our applications, removing the classpath extension and forcing each application to depend only on the classes within its own jar (hence the 'self-contained' in the title). The needed client interfaces of other modules were built into the application jar at build time. This gave us hot deploy again.

      The problem was that this new configuration, when we run our entire test suite, takes nearly 3 times as long to complete as when we had the common client jars in jboss own classpath.

      I don't have the knowledge to be able to work out what's going on. Not a single line of our application code has changed, simply the way the classes are organised. The only difference in the jboss configuration is the extra classpathextension element in jboss.conf.

      Anyone seen this behaviour before? It's not such a big problem for deployment since I can always revert to the faster configuration, but it slows development down enormously. My developers have all reverted to the previous, more static configuration, where you had to stop jboss while building modules.

      Anyone know what is causing this problem? I thought it might be a classloading issue but don't know enough about jboss' classloading to be sure.


        • 1. Re: Performance drop using self-contained jars?
          David Jencks Master

          Almost certainly with the slow configuration jboss is required to serialize (un-optimize) the calls between beans in different jars.

          The ScopedDeployer was designed to fix this by creating an extensible and de-extensible classloader so one application could be loaded from many independent jars. I'm pretty sure it's available in jboss 2.4.3, however it may only deploy ears. However it might not be too hard to package each jar into an ear. I've never actually set it up, but I believe you replace the J2eedeployerMBean with it in jboss.jcml.

          This classloader idea is the basis for the jboss 3 classloading system, which now applies to everything in jboss, not just ejbs.