2 Replies Latest reply on Aug 30, 2002 12:02 PM by Sander Bos

    JBoss classloaders vs. the default JVM classloader

    Sander Bos Newbie

      Hi there,

      Does anybody know about the JBoss classloaders being significantly slower than the default JVM classloaders?

      I am using JBoss 3.0.0, with JDK 1.3.1 on both Linux and Windows 2000. I used Xerces 2.0.1, but I suspect the same problem occurs for any Xerces.

      I've been hunting down a performance problem, and I have found it now. I made a reproducible test case for it. I attached that test-case, if you have ant it is reasonably easy to compile/ run.

      What the test does is do 1000 client-server requests to parse a small file with Xerces (that I do not use jaxp is intentional, I want 'my' jars to be used for the parsing). I time how long this takes from the client perspective.

      Now if I ran the test with two configurations:
      - Scenario 1: sample-bean jar in server/default/deploy, and the Xerces jars in server/default/lib.
      - Scenario 2: sample-bean jar in server/default deploy, and Xerces jars added to the JBoss classpath, like so:
      set JBOSS_CLASSPATH=d:\cl\jars\xercesImpl.jar;d:\cl\jars\xmlParserAPIs.jar
      and not in any JBoss directory.

      Here are the times for the parsing of 1000 docs:
      - Scenario 1: 36 seconds
      - Scenario 2: 13 seconds...

      I respect that the JBoss classloaders does some extra checks or something, but not that it becomes 3 times slower. Has anybody else experienced this? Is this what should be expected? Can something be configured to make it faster?
      Most importantly: What should we advise our customers (we have an EJB binding, currently we advise people to configure it according to scenario 1....).

      (It has nothing to do with Xerces. I just made a test-case with Xerces so you or somebody else may reproduce it, the problem was found when testing our own software)

      Kind regards,


      P.S.: The forum does not like attachments, so you can now actually download it from

        • 1. Re: JBoss classloaders vs. the default JVM classloader
          Marcin Newbie

          Looks like i have the same problem. We wrote quite big application based on Cocoon 2, and running it on JBoss 2.4.3 is about 3 times faster that on JBoss 3.0.2.

          Optimization software indicates that most of the time is spent in java.net.URLClassLoader which is used by org.jboss.mx.loading.UnifiedClassLoader.getResource() method. The last one method is used by xalan and xpath.

          This issue blocks our project from moving to jboss 3 and running it on the cluster.

          Someone can explain why it happens and if can we expect fixing of this problem?


          • 2. Re: JBoss classloaders vs. the default JVM classloader
            Sander Bos Newbie

            Dear Marcin,

            in a way it is good to know that I am not the only one with this problem.

            I reply only to say that I have reposted the question in the 'Installation & Configuration' forum (with the same subject as here). A JBoss developer has reacted, but only to say to try a newer JBoss so far. Anyway, sorry about the crossposting, but maybe it is better to discuss the topic further there (I reposted because there seem to be more eyes watching in that forum).

            Kind regards,