Memory, in general, is not an issue here Sockets in RMI arent a limitation either

located inside a much smaller number of JVMs. One sure tip-off that the design has gone bad is the realization that theres a scarce resource to which all your servers require exclusive access. Sometimes this is obvious. For example, consider our printer server. It makes little or no sense to create multiple printer servers connected to the same printer™its not even clear what a second printer server would do Other times, this is more subtle and requires a fair amount of thought.

6.2.1.1 Memory, in general, is not an issue here

As long as the instances of servers can comfortably reside within a single JVM, memory is not an issue. The amount of memory required by a server can be divided into two pieces: client-specific state and general-purpose state. For example, in an e-business application, the clients current order is clearly client-specific; the general catalog of items available for sale is general-purpose. Generally speaking, the amount of memory required by a set of servers is a constant the general-purpose state plus an amount proportional to the number of currently active clients. However, the latter value is often proportional to the number of currently open socket connections. This is one example of why memory is not going to be the bottleneck. Youll swamp other scarce resources long before memory becomes a problem that cant be solved by popping more memory modules in the machine. This might seem false in the case of our accounts. If there are 25 million accounts, then the amount of memory required for 25 million server objects would seem to be substantial, independent of the number of clients currently connected. The factory pattern, which we discuss in Chapt er 17 , is designed to explicitly handle this problem.

6.2.1.2 Sockets in RMI arent a limitation either

It used to be that socket allocation was a major resource limitation. This was caused by the combination of two factors: • Processes on most major operating systems were only allowed to have a limited number of sockets open. [ 3] In fact, the actual limit is usually the number of file descriptors a process can have open; file descriptors are used for both files and sockets. [ 3] The limit is built into the operating system and is usually less than or equal to 1024. • Each server required an instance of ServerSocket to listen for connections. The combination of these two factors is deadly. It means that a very small number of servers can be running inside a single process. And since launching a process in Java requires launching a JVM, which consumes a significant amount of memory and operating-system resources, this can quickly become a major issue. RMI [ 4] solves this problem by reusing sockets. In other words, if a client JVM sets up a socket connection to a server JVM, then the connection is actually kept alive for a short period of time by the RMI infrastructure. If, after the client request has been handled, a second request is made from the same client JVM, that request will reuse the same socket connection. This means that the number of socket connections required by an RMI server is approximately: 1 + number of simultaneous requests. [ 4] That is, the Sun Microsystems, Inc. implementation of RMI. Socket sharing isnt actually required by the RMI specification. This is only an approximation because there may be temporary open, unused socket connections that correspond to completed requests. In practice, this can be significant. If you find that unused sockets are being retained for long periods of time and constitute a significant resource limitation, then you can either set parameter values to configure how long the RMI runtime keeps unused sockets open well discuss this, and other settings, in Chapt er 16 or use a custom socket factory to achieve a similar effect well discuss custom socket factories in Chapt er 18 . Note that this number is entirely dependent on the number of clients and how busy they are. It does not depend at all on the number of servers. Socket reuse is actually a fairly significant benefit to using RMI. Its not all that hard to implement, but doing it right requires a fair amount of code and some forethought. The RMI Runtime Now that weve discussed sockets, its time to admit that our architectural diagrams are hiding a bit of the complexity of RMI. Neither stubs nor skeletons use sockets directly. Instead, stubs use an object called a RemoteRef , which handles the actual details of communicating with a remote process. This extra layer of indirection allows the RMI infrastructure to manage network communications and conserve scarce resources. From the networking point of view, it makes both socket sharing and distributed garbage collection possible. It also enables RMI to effectively share a thread pool across multiple servers. Well explore this much more fully in Par t I I . The networking details are covered in Chapt er 16 , and thread pools are discussed in Chapt er 11 and Chapt er 12 . Well ignore the RMI runtime for the rest of this chapter and for the rest of Part 1. However, its not a bad idea to keep the fact that sockets are shared in the back of your mind. Its also good to remember that when we draw a stub and a skeleton in a picture, we really mean something like that shown in Figur e 6- 1 . Figure 6-1. Stubs and skeletons interact with the RMI runtime and not directly with the network

6.2.1.3 An example of a resource limitation