[Jboss-dev-forums] [Deployers on JBoss (Deployers/JBoss)] - Random OutOfMemoryError on the initial deploy of conf/jboss-

[<dim...@jb...>]

(Moving here from private discussion)

This is relatively easy to reproduce by using any out of-the-box jboss v4.0.2/4.0.3SP1 on a linux/sun 64bit 1.5.0_05 jdk (e.g. dev17).

One out of ten times, or so, we get an OOM Error just when the UCL associated with conf/jboss-service.xml and all the server/libs is trying to open tmp/deploy/tmpNNNNNjboss-service.xml with java.util.zip.ZipFile(), looking for the very first mbean class referenced in conf/jboss.service.xml.

The whole thing starts with MainDeployer.deploy(file: ... /conf/jboss-service.xml)

conf/jboss-service.xml (or any other deployment be it a packaged one or a simple xml descriptor) is copied by default due to the MainDeployer copyFiles==true, but this is not really the problem: I tried with copyFiles==false and still get the OOM Error.

Now, either the original (conf/jboss-service.xml) or the copy 
(tmp/deploy/tmp31494jboss-service.xml) get on the classpath 
because we wrap the deployed URL with a DeploymentInfo and 
then we do a:
 
  // initialize the unified classloaders for this deployment
  deployment.createClassLoaders();
 
That creates the UCL pointing to the xml descriptor:
 
  // the classes are passed to a UCL that will share the classes with the whole base
   Object[] args = {localUrl, origUrl, Boolean.TRUE};
   String[] sig = {"java.net.URL", "java.net.URL", "boolean"};
   ucl = (RepositoryClassLoader) 
server.invoke(repositoryConfig.repositoryName,
            "newClassLoader",args, sig);
 
Onto which the referenced lib/*.jars are added:
 
   // Add any library jars seen before the UCL was created
   if( classpath.size() > 0 )
    {
       Iterator jars = classpath.iterator();
        while( jars.hasNext() )
         {
           URL jar = (URL) jars.next();
           ucl.addURL(jar);
          }
      }

The bootstrap descriptor is not different from any other deployment.

I'm not sure if a solution would be to pass a *null* URL to 
"newClassLoader", if the DeploymentInfo points to an .xml 
descriptor, to avoid having the base URLClassLoader trying to 
ZipFile.open() it, since we know there won't be any classes/resources in there.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3915911#3915911

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3915911