United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-6332603 : custom socket factories used to export a remote object not garbage collected

Details
Type:
Bug
Submit Date:
2005-10-04
Status:
Open
Updated Date:
2013-04-12
Project Name:
JDK
Resolved Date:
Component:
core-libs
OS:
generic
Sub-Component:
java.rmi
CPU:
generic
Priority:
P4
Resolution:
Unresolved
Affected Versions:
5.0
Targeted Versions:

Related Reports
Relates:
JDK-4486732 - RMI custom client socket factories not getting garbage collected
Relates:
JDK-6279965 - complete 4457683 fix: release server socket originally created for exports on anonymous ports too

Sub Tasks

Description
When an RMIClientSocketFactory or RMIServerSocketFactory instance is used to export a remote object (with UnicastRemoteObject, Activatable, or LocateRegistry.createRegistry), that instance becomes pinned for the lifetime of the VM by the RMI implementation: it and its dependencies (such as its class's defining class loader and all other classes that that loader has defined) can never be garbage collected, even after the remote object has itself been garbage collected or otherwise unexported.  This pinning is rooted in the static table "localEndpoints" in the sun.rmi.transport.tcp.TCPEndpoint class.

(This bug is the server-side analogue of 4486732, which has been fixed.)

Comments
EVALUATION

Regarding the JDC/SDN comments of 2006-11-15:

No, this bug (which only applies when a remote object is exported with custom socket factories anyway) is not related to the ongoing presence of the non-daemon "RMI Reaper" thread that keeps the VM alive as long as there remain application remote objects exported.  If that thread persists, then it indicates that your remote object remains reachable either locally or from a remote client that still has a live remote reference to it.  Logging or heap dump analysis would help determine that.  You can force the remote object to be unexported (as opposed to letting it get unexported implicitly via garbage collection) by using the UnicastRemoteObject.exportObject method, after which (if it was the only one) the "RMI Reaper" thread should go away.
2006-11-16 
EVALUATION

Regarding the JDC/SDN comments of 2006-10-26:

No, this bug is not related to "RMI RenewClean-" threads.  The "RMI RenewClean-" threads are "client-side" in the sense that they exist because of remote references (a.k.a. remote stubs) instead of exported remote objects.  This bug is a "server-side" issue, caused by the exporting of remote objects.  It had a client-side analogue, 4486732, that once a remote invocation had been made on a remote reference with a given RMIClientSocketFactory value, an object of that value would be pinned forever (not allowed to be garbage collected).  But that's also not directly related to "RMI RenewClean-" threads, which only persist while remote references with the corresponding host/port/socket-factory combination are otherwise reachable in the VM.  See 5053529 for a bug report specifically about (the potentially high number of) "RMI RenewClean-" threads.
2006-11-02 
EVALUATION

Yes, this is a bug: after all remote objects that had been exported with a given socket factory value have become unexported (either explicitly or through garbage collection), instances of that factory value should no longer be strongly reachable through the RMI implementation.
2005-10-04


Hardware and Software, Engineered to Work Together