[jboss-dev] Possible blocker with jboss-cl 2.2.0.Alpha1 [WAS]: Hudson Jobs Hanging

[Adrian Brock]

On Tue, 2010-02-16 at 13:46 +0100, Carlo de Wolf wrote:
> Another one:
> 
> 13:29:34,336 ERROR [STDERR] Exception in thread "WorkerThread#0[127.0.0.1:51198]" java.lang.NoClassDefFoundError: sun/reflect/SerializationConstructorAccessorImpl
> 13:29:34,338 ERROR [STDERR] 	at sun.misc.Unsafe.defineClass(Native Method)
> 13:29:34,338 ERROR [STDERR] 	at sun.reflect.ClassDefiner.defineClass(ClassDefiner.java:45)
> 13:29:34,339 ERROR [STDERR] 	at sun.reflect.MethodAccessorGenerator$1.run(MethodAccessorGenerator.java:381)
> 13:29:34,339 ERROR [STDERR] 	at java.security.AccessController.doPrivileged(Native Method)
> 13:29:34,339 ERROR [STDERR] 	at sun.reflect.MethodAccessorGenerator.generate(MethodAccessorGenerator.java:377)
> 13:29:34,340 ERROR [STDERR] 	at sun.reflect.MethodAccessorGenerator.generateSerializationConstructor(MethodAccessorGenerator.java:95)
> 13:29:34,340 ERROR [STDERR] 	at sun.reflect.ReflectionFactory.newConstructorForSerialization(ReflectionFactory.java:313)
> 13:29:34,341 ERROR [STDERR] 	at java.io.ObjectStreamClass.getSerializableConstructor(ObjectStreamClass.java:1327)

<snip/>

> 13:29:34,349 ERROR [STDERR] 	at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObjectVersion2_2(JavaSerializationManager.java:12
> 
> Basically a class loader should always have the capabilities of the boot 
> class loader.

No it shouldn't. Doing that would break the isolated classloading.
e.g. We'd never be able to override the jaxb version to 2.1 when
using jdk6
e.g.2 Putting your own version of xerces (which is on our classpath)
in a webapp.
e.g.3 You can filter what classes are (in)visible from the classpath,
see for example the OSGi spec rules.

In this case, this is a long standing bug in the Sun JDK, 
for which we have a workaround.
https://svn.jboss.org/repos/jbossas/projects/jboss-cl/trunk/classloader/src/main/java/org/jboss/classloader/spi/jdk/JDKChecker.java

However, this workaround doesn't get used if the classloader
gets shutdown.

I can add the use of the JDKChecker to the part that gets run
after a classloader is shutdown, but we're just playing "whack-a-mole".
The real problem is that the classloader should not have leaked.

Incidently, jboss-cl-2.2.x has an experimental new feature 
called "ShutdownPolicy".
http://community.jboss.org/thread/147089

So changing conf/bootstrap/classloader.xml to have


   <!--
      The classloader implementation
   -->
   <bean name="ClassLoaderSystem"
class="org.jboss.classloader.spi.ClassLoaderSystem">
      <classloader><null/></classloader>
      <constructor
factoryClass="org.jboss.classloader.spi.ClassLoaderSystem"
factoryMethod="getInstance"/>

      <!-- HERE -->
      <property name="shutdownPolicy">Garbage_Collection</property>

   </bean>

Would allow the classloader to use the domain even after undeployment.
But it wouldn't solve all the problems since it wouldn't be able to
see other undeployed classloaders if it uses import-all=true.

It would also mean you don't get error messages like the ones above that
help you understand that you are leaking classloaders.

> (Apart from the real issue: class loader is shot before response leaves 
> the server.)


-- 
xxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Chief Scientist
JBoss by Redhat
xxxxxxxxxxxxxxxxxxxxx