sun.rmi.dgc.client.gcInterval sun.rmi.dgc.server.gcInterval

There are several factors to consider when altering this value. If leases last for a long time, the server runtime will keep references to servers for long periods of time when a client behaves badly. Since the point of distributed garbage collection is to enable the server to release resources, this may not be a good thing when either the client application or the intervening network are unstable. On the other hand, short-lived leases have problems as well. They result in increased network traffic leases must be renegotiated fairly often and make the application much more sensitive to temporary network problems. For example, if the network goes down for longer than the duration of a lease, the server might very well clean up a server, even if the client is still trying to use the server. This last point is especially important™your application may suffer performance problems if you grant long-lived leases. But the consequences of leases that are too short are almost certainly worse; its not just performance that is affected, but functionality as well. Also note that leases are intended to be much larger than the typical network latency for a request. Clients try to renew leases when they are halfway over. Suppose you tried to have a very short lease time, relative to your network latency. For example, you tried to grant 15-second leases on a slow, congested network. Something like the following sequence of events may occur: 1. The client runtime requests a lease. 2. Five seconds later, the server runtime gets the request and grants a 15-second lease. 3. Five seconds later, the client runtime gets the response and starts a timer going. 4. Seven seconds later, the client running attempts to renew the lease. 5. Five seconds later, the server runtime gets the renewal request. However, by this time, 17 seconds have elapsed since the server runtime granted the lease, and the server runtime may already have released the server for garbage collection. This is undesirable; leases that are too short are, essentially, unrenewable. This can render an application unusable. The fact that clients try to renew leases when they are halfway expired suggests another rule of thumb: if bandwidth is a concern, then the typical lease should be more than twice the length of an average client session. This minimizes the network overhead due to the client lease in the average case, a single call to dirty and a single call to clean while still allowing the distributed garbage collector to do its work. We should admit one further thing. Setting lease durations is very much fine-grained tuning of an application. It doesnt actually affect the design of your application and should only be done once the application is deployed and a problem is noticed.

16.4.4.2 sun.rmi.dgc.client.gcInterval

This parameter configures client runtime behavior. The basic question is this: how often does RMI check to see whether a stub is no longer referenced by the rest of the client application? Once a stub is not referenced by the rest of the client application, the client runtime is free to send a clean message to the server runtime. sun.rmi.dgc.client.gcInterval is specified in milliseconds and defaults to 1 minute i.e., the default value is 60,000. The trade-off here is client-side computational resources versus improved server latency. That is, decreasing this value will result in increased client overhead but potentially release server resources faster. How does the runtime know when a stub is no longer referenced by the client application? The answer is complicated. But the basic idea is that the RMI runtime doesnt really retain references to the stub. Instead, it uses instances of WeakReference defined in the java.lang.ref package. A weak reference is a reference that does not prevent an object from being garbage collected. That is, if the object referred to has no other references other than weak references, an attempt to get the actual reference from weak references will return null. Otherwise, the weak reference can be used to get a valid reference to the object. The RMI runtime retains weak references to stubs. If the weak reference resolves to null, the RMI runtime knows that no other part of the client application has a reference to the stub and that, therefore, it should call clean on the server. At a minimum, the RMI runtime checks whether the weak reference resolves to null before renewing a lease. However, the RMI runtime also does periodic checks of all the stubs to which it has weak references. Thats what sun.rmi.dgc.client.gcInterval is really controlling.

16.4.4.3 sun.rmi.dgc.server.gcInterval

This is similar to sun.rmi.dgc.client.gcInterval ; the difference is that this controls the server sides refresh rate for distributed garbage collection. The server receives a number of clean messages and also occasionally expires leases. This parameter controls how often the server examines the consequences of these actions and attempts to determine whether unreferenced should be called. sun.rmi.dgc.server.gcInterval is specified in milliseconds and defaults to 1 minute i.e., the default value is 60,000.

16.4.4.4 sun.rmi.dgc.checkInterval