Performance drop using self-contained jars?
drcharris Feb 17, 2002 12:50 PM(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.
c