sun.rmi.dgc.checkInterval sun.rmi.dgc.cleanInterval

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

This specifies how often RMI checks for expired leases. That is, the server runtime maintains a list of active leases, including the time they were granted. Every so often, a background thread goes through the list looking for leases that have expired. sun.rmi.dgc.checkInterval is specified in milliseconds and defaults to 5 minutes i.e., the default value is 300,000. There is a relationship between this value and that of java.rmi.dgc.leaseValue : they should be reasonably proportional, taking into account the number of clients. That is, if you expect to have 5 clients with long-lived sessions, and theyre consequently getting leases that last for 24 hours, it makes very little sense to set sun.rmi.dgc.checkInterval to check for expired leases every 5 seconds. The rule of thumb: if you expect a lease to expire every n seconds, then you should set sun.rmi.dgc.checkInterval to approximately 1000n 1,000 because, like all the duration parameters, this is specified in milliseconds.

16.4.4.5 sun.rmi.dgc.cleanInterval

This is a retry parameter for clients. If a client calls clean and the operation fails e.g., if the network is down, this parameter specifies how long the client waits before trying to call clean again. It defaults to 3 minutes 180,000 milliseconds. Of the parameters that affect distributed garbage collection, sun.rmi.dgc.cleanInterval is the least important.

Chapter 17. Factories and the Activation Framework

In Chapt er 14 and Chapt er 15 , we discussed how to build a better naming service, one that has a great deal more flexibility than the RMI registry and enables easier lookup of specific servers. However, applications that could potentially have millions of servers still require more infrastructure to help them deal with resource management. In this chapter, well discuss the most common way of achieving this, the factory pattern, and how it is supported in RMI. To do this, well implement a basic factory directly, and then implement similar functionality using RMIs activation framework.

17.1 Resource Management

Our bank example has so far been a small-scale application. While Account is a fairly flexible interface, and you may think you can support millions of accounts using our new naming service and one of the implementations of Account that weve discussed, the fact of the matter is that more infrastructure is required. To see why, consider the Bank of America advertisement quoted in Chapt er 5 : When traveling, take advantage of more than 13,000 Bank of America ATMs coast to coast. Were in 30 states and the District of Columbia. As a Bank of America Check Card or ATM cardholder, theres no ATM fee when you use an ATM displaying a Bank of America sign... ™Bank of America advertisement Thats 13,000 dedicated client machines. Plus, there are the client applications running inside each branch of the bank, the central reporting and analysis applications each division of the bank runs, and all the new Internet services that our hypothetical bank wants to roll out over the next few years. In short, we have the following situation: A potentially unbounded number of client applications running over a period of time. Practically speaking, there wont be many more clients running than there are accounts. So a good upper boundary on the number of clients is the number of open accounts. For a large bank, this can be over 10 million. Most servers will be active occasionally. Most people look at their account balances and information at least once a month. In addition, automatic bill-paying programs and other advanced services will probably require access to account information. Most servers will be inactive most of the time. Most people dont look at their account balances and information more than once a day. Since such usage, along with monthly and weekly reporting functionality, is the vast majority of anticipated use, it follows that most accounts will be inactive most of the time. Most clients want to access a small number of accounts for a short period of time. Were assuming our previous model of client-interaction is probably correct for most applications.