I think I have found the problem. In ClassLoadingAwareObjectInputStream.java
the load() method makes a call to Class.forName().
For the primitive types (int, boolean, etc.) this would result in a call
similar to:
Class.forName("int", false, loader); //Where loader is the
Applet2ClassLoader
Since Applet2ClassLoader is a URLClassLoader and "int.class" is not in the
jar cache it pulled down from the server at the start of application, it is
going to try and go to the server to resolve this class.
In the event of a network failure, this will result in the ClassLoader
having to wait for the socket timeout. (see stacktrace in previous post)
Once this socket timeout occurs, the load() method then attempts to lookup
the class in the primitive HashMap that is statically initialized. This
returns the class for the int and the deserialization continues on.
At first it seemed like the messages were failing to be received but it
turned out they were just taking a very long time to be deserialized. This
problem can be avoided by changing the order in which
ClassLoadingAwareObjectInputStream tries to resolve the class. Here is the
change I made to the load() method:
Please let me know how I can o about getting this incorporated into the
ActiveMQ trunk. Thanks.
private Class<?> load(String className, ClassLoader... cl) throws
ClassNotFoundException {
//Check to see if this is a primitive first
final Class<?> clazz = (Class<?>) primClasses.get(className);
if (clazz != null) {
return clazz; //return the primitive class found in the map
} else {
for (ClassLoader loader : cl) {
try {
return Class.forName(className, false, loader); //for
applets this may be a URLClassLoader
} catch (Exception ex) {
// ignore
}
}
//if we still haven't found the class, use the fallback
return Class.forName(className, false, FALLBACK_CLASS_LOADER);
}
}
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Applet-Class-Loader-Problems-tp4671835p4671856.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
