Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2110110 | 1.4.0 | Scott Seligman | P3 | Resolved | Fixed | beta2 |
Name: krC82822 Date: 02/10/2001
java version "1.3.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0)
Java HotSpot(TM) Client VM (build 1.3.0, mixed mode)
Sun's JNDI implementation caches ClassLoaders in the static Hashtable
"propertiesCache" in com.sun.naming.internal. The problem method is
"getApplicationResources," and the class loader is obtained by
helper.getContextClassLoader().
At the very least, the reference to the class loader should be
made a weak reference.
Because the ClassLoader is never freed, it cannot be garbage collected. That
causes two problems with servlet engines that depend on class reloading.
1. Obsolete classes can never be freed. The GC will never free the ClassLoader
because of the static reference. Because the ClassLoader isn't freed, none of
the classes loaded by the ClassLoader can be freed. That causes a huge memory
leak for servlet engines, which depend on GC to recycle class loaders.
2. This bug breaks JNI in servlet engines. JNI can only be loaded in a single
class loader. When a servlet engine reloads classes, it relies on GC to
recycle the obsolete class loaders. Since the ResourceManager.propertiesCache
has a reference to every classloader, the classloader will not be recycled.
Therefore users must restart the webserver to reload JNI.
(Review ID: 113882)
======================================================================
- backported by
-
JDK-2110110 JNDI breaks class reloading for web servers
- Resolved