JBoss classloaders vs. the default JVM classloader

[sanderbos]

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,

--Sander.

P.S.: The forum does not like attachments, so you can now actually download it from
http://support.xhive.com/downloads/extras/testcase.zip

[marcin]

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?

Regards
Marcin

[sanderbos]

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,

--Sander.