JDK-6495398 : When invalid rmi server is set, many RMI RenewClean threads consum too much memory
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.rmi
  • Affected Version: 1.4.2_08
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • OS: linux_redhat_4.0
  • CPU: x86
  • Submitted: 2006-11-20
  • Updated: 2010-08-05
  • Resolved: 2008-12-19
Related Reports
Relates :  
Relates :  
Description
When invalid server information(host name or IP address) is set to java.rmi.server.hostname 
property, a lot of  "RMI RenewClean-[....]" threads appears in client side and cause memory 
exhaustion finally.


CONFIGURATION : 
 OS : RHEL 4
 JDK : 1.4.2_08

REPRODUCE:
 1) Compile the attached java programs
   % javac *.java
   %  rmic -classpath . ServerImpl
 2) Invoke Server side program
  % java -cp . -Djava.rmi.server.hostname=1.1.1.1 ServerImpl 9999
 3) Invoke Client side program
  % java -cp . Client 127.0.0.1 9999

NOTE: 9999 is port number.

  The sample programs communicate every 10 seconds in RMI.
  At client side, the following message will shows up many times.
    java.rmi.ConnectIOException: Exception creating connection to: 1.1.1.1; nested exception is: 
    java.net.NoRouteToHostException: No route to host

Comments
EVALUATION This issue is ultimately related to RFE 5053529, which is to re-implement the client-side DGC threading model so that there are not "RenewClean" threads per remote endpoint (contained in live remote references) anymore. In other words, when 5053529 is addressed, this issue would go away. This bug report is inconsistent about exactly which RemoteException is being thrown from remote invocations to the "invalid" address-- the Description section describes this exception: java.rmi.ConnectIOException: Exception creating connection to: 1.1.1.1; nested exception is: java.net.NoRouteToHostException: No route to host whereas the attached log file contains this exception: java.rmi.ConnectException: Connection refused to host: 1.1.1.1; nested exception is: java.net.ConnectException: Connection refused The distinction could be very significant, because in the first case (java.net.NoRouteToHostException wrapped in a java.rmi.ConnectIOException), the observed issue may be caused by bug 6199638, which is currently only fixed in JDK 6. With 6199638, if the RemoteException thrown from remote invocations to a problematic remote endpoint (host, port, & client socket factory) is not a java.rmi.ConnectException (for example, if it is a java.rmi.ConnectIOException), then a "RenewClean" thread associated with that endpoint will never go away-- but if the number of live remote references containing that endpoint transitions to zero and later greater-than-zero again, another such "RenewClean" thread will be created, leading to accumulation of these threads. The nature of the provided test case tends to provoke the likelihood of accumulation of "RenewClean" threads (either temporarily, or permanently in the cases affected by 6199638) because it frequently varies the number of live remote references to a certain remote endpoint between zero and greater-than-zero. The effect depends on local garbage collection timing-- if the unreachable "server" stub is garbage collected during the ten-second wait, then during the next iteration, a new "RenewClean" thread will be created when the live reference count increments greater than zero again, but the old "RenewClean" will linger while attempting to complete the DGC clean call. It will linger for the duration of the retry attempts (or forever, in the cases affected by 6199638). The interval between retries is by default three minutes, although it can be controlled with the value of the system property "sun.rmi.dgc.cleanInterval" (specified in milliseconds): http://java.sun.com/javase/6/docs/technotes/guides/rmi/sunrmiproperties.html Setting this property to a smaller value will decrease the time that it takes for these "RenewClean" threads to give up retrying and go away (for cases not affected by 6199638, of course). So in summary: if the exception case causing the customer's primary problem is actually java.rmi.ConnectIOException: Exception creating connection to: 1.1.1.1; nested exception is: java.net.NoRouteToHostException: No route to host then that would explain permanent accumulation of "RenewClean" threads, and this bug should be considered a duplicate of 6199638 (fixed in JDK 6). If instead the exception case is just java.rmi.ConnectException, then then temporary excess accumulation of "RenewClean" threads can be ameliorated by a smaller "sun.rmi.dgc.cleanInterval" system property setting. (And in any case, implementing 5053529 would address the whole family of issues related to the number of "RenewClean" threads.)
20-11-2006