-
Enhancement
-
Resolution: Won't Fix
-
P3
-
8, 9
-
generic
-
generic
A DESCRIPTION OF THE REQUEST :
In modular environments such as Java EE containers, modules may be frequently loaded and unloaded. Modules are typically allocated a dedicated class loader. If a memory leak occurs, the module class loader can be pinned in memory which can, over time, lead to OOME.
In order to act on these leaks, the container needs to be able to identify them. Currently, this is only possible via reflection. With Java 9, this reflection approach will no longer work unless the JVM is started with the command line option "-XaddExports:java.rmi/sun.rmi.transport=ALL-UNNAMED".
This request is to provide a public API to allow containers to enumerate and deregister registered RMI Targets.
For more background see:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040893.html
JUSTIFICATION :
The only way to detect this memory leak in Java 9 requires the use of "-XaddExports:java.rmi/sun.rmi.transport=ALL-UNNAMED".
A public API for the enumeration of registered RMI Targets is a much cleaner solution.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I have no strong preference for the exact signature or location of this method but the ability to do something along the following lines is what I have in mind.
List<Registry> registryList = LocateRegistry.list();
for (Registry registry : registryList) {
String[] entries = registry.list();
for (String entry : entries) {
Remote remote = registry.lookup(entry);
if (/* some test on remote */) {
registry.unbind(entry);
}
}
}
ACTUAL -
The current reflection based code may be found here:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoaderBase.java?view=annotate#l2070
---------- BEGIN SOURCE ----------
Test cases I have been using to explore various ways RMI based memory leaks occur:
https://github.com/markt-asf/memory-leaks/tree/master/src/org/apache/markt/leaks/rmi
These can easily be adapted to test potential solutions or to form test cases.
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
See WebappClassLoaderBase code referenced above.
In modular environments such as Java EE containers, modules may be frequently loaded and unloaded. Modules are typically allocated a dedicated class loader. If a memory leak occurs, the module class loader can be pinned in memory which can, over time, lead to OOME.
In order to act on these leaks, the container needs to be able to identify them. Currently, this is only possible via reflection. With Java 9, this reflection approach will no longer work unless the JVM is started with the command line option "-XaddExports:java.rmi/sun.rmi.transport=ALL-UNNAMED".
This request is to provide a public API to allow containers to enumerate and deregister registered RMI Targets.
For more background see:
http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-May/040893.html
JUSTIFICATION :
The only way to detect this memory leak in Java 9 requires the use of "-XaddExports:java.rmi/sun.rmi.transport=ALL-UNNAMED".
A public API for the enumeration of registered RMI Targets is a much cleaner solution.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
I have no strong preference for the exact signature or location of this method but the ability to do something along the following lines is what I have in mind.
List<Registry> registryList = LocateRegistry.list();
for (Registry registry : registryList) {
String[] entries = registry.list();
for (String entry : entries) {
Remote remote = registry.lookup(entry);
if (/* some test on remote */) {
registry.unbind(entry);
}
}
}
ACTUAL -
The current reflection based code may be found here:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/loader/WebappClassLoaderBase.java?view=annotate#l2070
---------- BEGIN SOURCE ----------
Test cases I have been using to explore various ways RMI based memory leaks occur:
https://github.com/markt-asf/memory-leaks/tree/master/src/org/apache/markt/leaks/rmi
These can easily be adapted to test potential solutions or to form test cases.
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
See WebappClassLoaderBase code referenced above.