sun.rmi.server.activation.debugExec

performance by preventing a large number of really costly operations such as spawning a JVM from occurring at the same time. The default value for sun.rmi.rmid.maxstartgroup is 3 ms.

17.6.6.6 sun.rmi.server.activation.debugExec

This is the simplest, and possibly the most useful, of the rmid parameters. Its boolean valued. If its set to true , then the activation system will print out the command line used to create JVMs. This can really help in debugging an activatable system. You get to see exactly what parameters and properties are set in the created JVMs. The default for sun.rmi.server.activation.debugExec is false . In addition to these parameters, has some security -related parameters that we will discuss in Chapt er 19

17.7 A Final Word About Factories

In this chapter, we discussed the idea of a factory. At its most fundamental level, a factory is a server that launches other servers in response to client demands. However, a factory is more than just a remote constructor; its also a way to share resources among clients, and its a very convenient place to insert code that manages the server lifecycle. Theres another interesting point lurking here. Factories simplify client applications by providing client applications with the illusion of persistent servers. Consider the typical account server in our example. From the clients point of view, this server is always up and always available. The client calls the factory, using a method call that looks quite a bit like a naming-system lookup call. In response, the client gets a stub to a server. As long as the client holds on to the stub, the distributed garbage collector will keep the server alive, and the stub will be a valid reference. If the client discards the stub and then makes another request to the factory, the client will get another stub. Its quite possible that in the interim, the account server was shut down, and the new stub the client gets is actually for an entirely different instance of Account but with the same state as the previous instance. However, this fact is completely hidden from the client application. This can be summarized in two points: • Factories enable the automatic launching and shutdown of servers and provide an ideal mechanism for inserting persistence code. As such, they greatly simplify the design and implementation of large sets of similar server objects. • Factories enable clients to be written as if all the associated servers are up all the time. They also greatly simplify the design and implementation of client code. These two points make factories an incredibly important and versatile tool in the fight against application complexity. Part III: Advanced Topics Chapter 18. Using Custom Sockets