The current client-side DGC implementation, when a DGC clean call fails with an Exception other than a ConnectException, always reschedules the clean call to be retried some time in the future, on the conservative assumption that the failure condition was transient. This rescheduling occurs even if there are no live remote references to the endpoint of the clean call that remain reachable in the VM-- normally, that condition is sufficient to cause the "RenewClean" thread associated with that endpoint to terminate, but a rescheduled clean call keeps it alive. (Also see 5053529.)

It is certainly possible, however, that the failure condition is not transient; for many types of (non-ConnectException) exceptions, it is even likely. One example is if the failure is a SecurityException because the endpoint's custom client socket factory does not have permission to connect to the endpoint's host and port-- that condition would likely never get resolved, and it is highly undesirable to keep the associated "RenewClean" thread alive forever because of it: doing so is a permanent resource leak.

More generally, it seems wrong to forever assume a transient failure condition:

- The current implementation stops retrying a clean call that has failed several times with a ConnectException (which likely, but not definitely, indicates a non-transient condition[*]). But the same logic could reasonably be applied for ConnectIOException (as is already done by the equivalent client-side DGC implementation for net.jini.jeri.BasicObjectEndpoint). And UnknownHostException too. And practically speaking, the same logic could also be applied for MarshalException and UnmarshalException, which seem unlikely to occur repeatedly because of a transient condition. (The network-friendliness of retry attempts should also be considered, as is already done for DGC dirty calls, perhaps in concert with dirty calls to the same endpoint.)

- Other types of exceptions are not generally expected for possibly-transient failures of DGC calls, so while some retry attempts are in general well-advised, if the exception is really unexpected, it seems unwise to hold resources indefinitely because of it, especially if there are no live remote references to the endpoint and thus lease renewals aren't being attempted.

This issue was discussed in the following RMI-USERS thread:

http://archives.java.sun.com/cgi-bin/wa?A2=ind0210&L=rmi-users&P=10329

[*] For some discussion about categorizing the "retry worth" of an exception thrown from a remote invocation, see:

http://davis.jini.org/servlets/ReadMsg?list=discuss&msgNo=554
http://davis.jini.org/servlets/ReadMsg?list=discuss&msgNo=555
http://davis.jini.org/servlets/ReadMsg?list=discuss&msgNo=561