java.rmi.dgc.leaseValue

16.4.3.1 sun.rmi.transport.connectionTimeout

RMI attempts to reuse sockets. Between individual uses, a socket is dormant. Dormant sockets use resources. If a socket is unused for a long period of time, the benefit gained from reusing the socket might be outweighed by the resource commitment the socket requires. RMI therefore includes the sun.rmi.transport.connectionTimeout parameter, which specifies how long a socket will remain dormant before RMI closes it. sun.rmi.transport.connectionTimeou t defaults to 15 seconds i.e., has a default value of 15,000. On slower networks, this value should be increased. You have to set this value on both the client and the server, since both are attempting to reuse the same socket. That is, if the server sets the value to 60 seconds and the client uses the default of 15 seconds, the client will close the socket after 15 seconds. In effect, the servers parameters are overruled by the clients parameters.

16.4.3.2 sun.rmi.transport.tcp.readTimeout

sun.rmi.transport.tcp.readTimeout is the value for the underlying sockets timeout. It controls how long RMI will wait while trying to read a byte before determining that the socket is no longer working. The value of this parameter is actually just passed directly to the socket via the sockets setSoTimeout method whenever RMI creates a socket. If RMI attempts to read from the socket, and the socket times out, the socket will throw an instance of java.io.InterruptedIOException . RMI catches the instance of InterruptedIOException and throws a RemoteException on the client side. sun.rmi.transport.tcp.readTimeout defaults to 2 hours i.e., has a default value of 7,200,000.

16.4.3.3 sun.rmi.transport.proxy.connectTimeout

sun.rmi.transport.proxy.connectTimeout determines how long RMI will wait while attempting to establish a socket connection between two JVMs. If the timeout is exceeded, RMI will throw an instance of RemoteException on the client side™the client is always the JVM attempting to initiate the connection. The default value of sun.rmi.transport.proxy.connectTimeout defaults to 15 seconds i.e., has a default value of 15,000. On slower networks, this value should definitely be increased.

16.4.4 Parameters That Affect the Distributed Garbage Collector

There are five parameters that affect the behavior of the distributed garbage collector. The most important of these is java.rmi.dgc.leaseValue , which sets the duration of leases issued by the RMI runtime in a particular JVM. The other four configure how the system deals with expired leases.

16.4.4.1 java.rmi.dgc.leaseValue

This parameter only affects servers; it is used to set a standard duration for leases granted by a particular server. It is specified in milliseconds, and it defaults to 10 minutes i.e., the default value is 600,000. 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