RMI QUESTIONS

10. Is there a way to get automatic notification as soon as a remote Java VM fails?

This is very desirable and is on our RFE list. A notification facility should be available in a future release.

11. Is it possible to write a new transport layer for RMI which does not use sockets? As a follow-up question, how about a transport layer that uses non-TCP based sockets?

We have designed the transport interfaces so that different implementations of these interfaces can be used by RMI.  In eariler releases, this abstraction was used for our purposes and was not exposed for general use. Now, in the 1.2 JDK release, RMI supports "client and server socket factories" that can be used to make RMI calls over non-TCP based sockets.

12. Is there only one socket connection between a client process and the server, no matter how many stubs exist in that client process?

RMI reuses the socket connections between client and server whenever possible. The current implementation creates additional sockets on demand when they are needed. For example, if the existing socket is in use by a call then a new socket is created for the new call. Typically, there are at least two sockets open since the distributed garbage collector needs to make remote calls when remote objects are returned from the server. If a cached connection remains unused for a period of time, the connection is closed.

13. At what point is there a "live" connection between the client and the server and how are connections managed?

When a client does a "lookup" operation, a connection is made to the rmiregistry on the specified host. In general, a new connection may or may not be created for a remote call. Connections are cached by the RMI-transport for future use, so if a connection is free to the right destination for a remote call, then it is used. A client cannot explicitly close a connection to a server, since connections are managed at the RMI-transport level. Connections will time out if they are unused for a period of time.

15. Is it possible for a remote object to be notified when all clients disconnect?

Yes. You can use the java.rmi.server.Unreferenced interface to provide the notification via the unreferenced method when all clients disconnect. However, if there is a reference in the registry, then the Unreferenced.unreferenced method will never be called.

16. In JDK1.1, why doesn't my server program exit when all clients disconnect?

In RMI, a server VM should exit if there are a) no outstanding client-held references to the remote objects in VM, and b) no non-daemon threads executing in the VM. However, just because there are no local or remote references to a remote object does not mean the object will be garbage collected in a timely fashion. It does mean that the remote object's memory can be collected to satisfy a memory allocation that would otherwise fail (with an OutOfMemoryError).

Although Java does not specify the timeliness of collection anyway, there is a particular reason for the what can seem like indefinitely-delayed collection of remote objects in the JDK 1.1 implementation. Under the covers, the RMI runtime holds a weak reference to exported remote objects in a table (to keep track of local as well as remote references to the object). The only weak reference mechanism available in the JDK 1.1 VM uses a non-aggressive, caching collection policy (well-suited for a browser), so objects that are only "weakly reachable" will not get collected until the local GC decides that it really needs that memory to satisfy another allocation. For an idle server, this could never happen. But if memory is needed, an unreferenced server object will be collected.

The next release of the JDK will include a new infrastructure that RMI will use to reduce significantly the number of conditions under which this problem occurs.

18. Am I allowed to have static fields in a remote interface?

Yes. An initializer is run in each VM that loads the remote interface, creating a new static variable with the specified values. So, you have a separate copy of this static variable in each Java VM that loads the remote interface.

SERIALIZATION QUESTIONS

1.Why must classes be marked serializable in order to be written to an ObjectOutputStream?

The decision to require that classes implement the java.io.Serializable interface was not made lightly. The design called for a balance between the needs of developers and the needs of the system to be able to provide a predictable and safe mechanism. The most difficult design constraint to satisify was the safety and security of Java classes.

If classes were to be marked as being serializable the design team worried that a developer, either out of forgetfulness, laziness, or ignorance might not declare a class as being Serializable and then make that class useless for RMI or for purposes of persistence. We worried that the requirement would place on a developer the burden of knowing how a class was to be used by others in the future, an essentially unknowable condition. Indeed, our preliminary design, as reflected in the alpha API, concluded that the default case for a class ought to be that the objects in the class be serializable. We changed our design only after considerations of security and correctness convinced us that the default had to be that an object not be serialized.

Security restrictions

The first consideration that caused us to change the default behavior of objects had to do with security, and in particular in the privacy of fields declared to be private,
package protected, or protected.  No such restriction can be made on an object once it has been serialized; the stream of bytes that are the result of object serialization can be read and altered by any object that has access to that stream. This allows any object access to the state of a serialized object, which can violate the privacy guarantees users of the language expect. Further, the bytes in the stream can be altered in arbitrary ways, allows the reconstruction of an object that was never created within the protections of a Java environment. There are cases in which the recreation of such an object could compromise not only the privacy guarantees expected by users of the Java environment, but the integrity of the environment itself.

6.  When a local object is serialized and passed as a parameter in an RMI call, are the byte codes for the local object's methods also passed? What about object coherency, if the remote VM application "keeps" the object handle?

The bytecodes for a local object's methods are not passed directly in the ObjectOutputStream, but the object's class may need to be loaded by the receiver if the class is not already available locally. (The class files themselves are not serialized, just the names of the classes.) All classes must be able to be loaded during deserialization using the normal class loading mechanisms.

8.  I create an object and then send it across the net using objectWrite() and receive it using objectRead(). If I then change the value of a field in the object and send it as before, the object that objectRead() returns appears to be the same as the first object and does not reflect the new value of the field. Should I be experiencing this behaviour?

The ObjectOutputStream class keeps track of each object it serializes and sends only the handle if that object is seen again. This is the way it deals with graphs of objects. The corresponding ObjectInputStream keeps track of all of the objects it has created and their handles so when the handle is seen again it can return the same object. Both output and input streams keep this state until they are freed.

Alternatively, the ObjectOutputStream class implements a reset method that discards the memory of having sent an object, so sending an object again will make a copy.