[smarlow]

Sun Developer Support tried to reproduce but wasn't able to yet.

They have a copy of the TestOOM standalone code and the following steps to reproduce. Let me know if you think they should try running TestOOM differently.

Steps to reproduce:

1. Download JBoss 4.0.3SP1 and unzip archive into your home folder (or where ever you please).
One of these links should work for you
http://prdownloads.sourceforge.net/jboss/jboss-4.0.3SP1.zip?download
http://sourceforge.net/project/showfiles.php?group_id=22866&package_id=16942&release_id=365509
http://www.jboss.com/products/jbossas/downloads

The rest of these instructions assume you extracted to home folder.

2. Save the attached TestOOM.class +TestOOM.java in your home folder an export CLASSPATH to include this folder (or where you put it).
cd
export CLASSPATH=./:$CLASSPATH

3. Put a xml file in the lib folder where there are a bunch of jars already
cd jboss-4.0.3SP1/server/all
cp conf/jboss-service.xml lib/

4. Run the test, most times it will get OutOfMemoryException
cd
java TestOOM jboss-4.0.3SP1/server/all/lib/ jboss-4.0.3SP1/server/all/lib/jboss-service.xml

-Scott

[dimitris]

You should be able also to skip (2) & (3) and for (4) you can reference directly the conf-jboss-service.xml, eg.

java -cp . TestOOM jboss-4.0.3SP1/server/all/lib jboss-4.0.3SP1/server/all/conf/jboss-service.xml

(I don't remember if it makes any difference whether the .xml file is in the same directory with the libs or not).

[smarlow]

Good news, Sun was able to reproduce the issue.

[dimitris]

Excellent! (how did you find out? :)

I see also on the bug report page a workaround:

set LD_ASSUME_KERNEL=2.4.1

[ken0624700]

Sun's bug page said it's fixed in Mustang and there's no available action to fix it in Tiger except the work around, which seems too risky to me.

Has anybody come up with a fix/workaround on the JBoss side? Thanks!

[ken0624700]

I found the similar problem occurred in RepositoryClassLoader - it loads jboss-service.xml into the URL list along with other JAR files and causes the same OOME problem sporadically.

I had to change the constructor of the class to skip adding the URL if it ends with XML, as in the following:

protected RepositoryClassLoader(URL[] urls, ClassLoader parent)
{
super( (urls == null || urls[0].toString().endsWith(".xml")) ? new URL[]{} : urls, parent);
this.parent = parent;
}

This resolves the problem.

[dimitris]

http://jira.jboss.com/jira/browse/JBAS-3110
The workaround found its way in 4.0.4.GA. This is by following the execution path from DeploymentInfo to the classloader.

Does your OOM occur at a different stage? (after the initial deployment of conf/jboss-service.xml)

[smarlow]

By the way, the Sun bug fix is also supposed to be checked into the 1.5.0_u8 release (I heard this from Sun support.)