RMI Release Notes - JDK 5 Documentation v1.4.0, Java 2 SDK 英文文档

RMI Release Notes for J2SETM 1.4

Documentation Contents

IllegalStateException trace output by RMI server virtual machine

When a virtual machine with exported remote objects is receiving remote calls under heavy load, an exception trace similar to the following may be output occasionally to System.err:

java.lang.IllegalStateException: Task already scheduled or cancelled
        at java.util.Timer.sched(Timer.java:316)
        at java.util.Timer.schedule(Timer.java:128)
        at sun.rmi.transport.DGCAckHandler.startTimer(DGCAckHandler.java:84)
        at sun.rmi.transport.ConnectionOutputStream.done(ConnectionOutputStream.java:82)
        at sun.rmi.transport.StreamRemoteCall.releaseOutputStream(StreamRemoteCall.java:94)
        at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:302)
        at sun.rmi.transport.Transport$1.run(Transport.java:148)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
        at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
        at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
        at java.lang.Thread.run(Thread.java:536)

Usually, the occurrence of this exception is otherwise harmless, although in some cases when clients attempt remote calls in rapid succession, the occurrence of the above exception can cause one future client remote call to fail with a java.rmi.UnmarshalException containing a java.io.EOFException. When this occurs, retrying the failed remote call will succeed. This problem will be fixed in the next maintenance release.

Server-side Stack Traces Now Retained in Remote Exceptions

The RMI runtime implementation will now preserve the server-side stack trace information of an exception that is thrown from a remote call, in addition to filling in the client-side stack trace as it did previous releases. Therefore, when such an exception becomes accessible to client code, its stack trace will now contain all of its original server-side trace data followed by the client-side trace.

This feature is made possible by the new "programmatic access to stack trace information" feature of java.lang.Throwable in J2SE 1.4, which included making a Throwable's stack trace data part of its default serialized form. What the client-side RMI runtime implementation now does to cooperate with this feature is to append the client-side trace to the unmarshalled server-side trace, rather than simply overwriting with the client-side trace as it did in previous releases.

Certain RMI server applications may wish to prevent any server-side stack trace data from accompanying an exception to be marshalled as the result of a remote call (as part of the exception's default serialized form in J2SE 1.4), perhaps for reasons of performance or confidentiality. In such cases, the implementation-specific system property

sun.rmi.server.suppressStackTraces

can be set to "true" to cause the server-side RMI runtime implementation to clear the stack traces of all exceptions thrown from the current virtual machine as the result of remote method invocations.

Service Provider Interface for RMIClassLoader

Certain static methods of java.rmi.server.RMIClassLoader now delegate their behavior to an instance of a new service provider interface, java.rmi.server.RMIClassLoaderSpi. The service provider can be configured to augment RMI's dynamic class loading behavior for a given application. By default, the service provider implements the standard behavior of all of the static methods in RMIClassLoader. See the class documentation of RMIClassLoader and RMIClassLoaderSpi for more details.

Dynamic Server Host Name

The java.rmi.server.hostname property can now be dynamically updated to indicate that future exports should use a new host name. Therefore, the new host name value will be contained in the stub for an object that is exported after the property is updated.

Serializing Primitive Class Objects

In previous releases, a ClassNotFoundException would be thrown if an attempt was made to pass a primitive Class object in an RMI call. Now, an object that contains Class objects for primitive types can be passed as a remote method parameter or return value, and can be stored in a java.rmi.MarshalledObject instance.

Enhanced RMI Implementation Logging

Sun's implementation of RMI in J2SE 1.4 now uses the new Logging APIs to provide implemention-specific logging output. See the RMI Implementation Logging page for more information.

Serialization Enhancements

See the Serialization Release Notes for more information on enhancements and improvements to Object Serialization in J2SE 1.4.

java.rmi.activation.ActivationGroupDesc (since 1.3)

The getClassName method, which returns the group's class name, can now return null, indicating the system's default group implementation. Previously, the getClassName method would return the name of the internal implementation class if the default group implementation was chosen when the descriptor was constructed.

Due to this change, if an application running in a 1.3 JVM registers an new activatable object with the ActivationSystem, rmid must also be upgraded to run 1.3, since a pre-1.3 rmid will not be able to activate the newly registered activatable object.

Constructors of activatable objects (since 1.3)

An activatable object's "activation" constructor, which takes an ActivationID and a MarshalledObjectas arguments and which is called by the ActivationInstantiator each time the object is activated, can now be private or protected. Previously, the implementation only allowed public activation constructors.

Serializing remote objects (since 1.2.2)

Prior to 1.2.2, an attempt to pass an unexported remote object in a RMI call would result in a java.rmi.StubNotFoundException. This exception was a result of the RMI runtime's failure to locate a stub object during an attempt to replace a remote object implementation with its corresponding stub. In 1.2.2 and later releases, an unexported remote object passed in an RMI call will no longer result in an exception, but rather the remote object will be serialized instead of its stub. If the remote object implementation is not serializable, an attempt to pass an unexported object in an RMI call will result in a java.rmi.RemoteException with the nested exception java.io.NotSerializableException.

java.rmi.server.RMIClassLoader (since 1.3)

java.rmi.server.RMIClassLoader has a new method, getClassLoader. This method returns the class loader that RMI uses to load classes from a specified codebase URL path. This API can be used in an implementation that requires complete RMI marshalling/unmarshalling behavior. See java.rmi.server.RMIClassLoader for details.

The RMI Stub Compiler, rmic

• By default, rmic now assumes that the destination directory for generated stubs is the package-named subdirectory of the current working directory. If the "-d" option is not specified, the result is the same as though it were specified with the current working directory "." as an argument. The "-d" may still be used to override the default destination directory.
• Two new options, "-idl" and "-iiop" have been added to generate IDL and stubs for IIOP, respectively.

The RMI Activation Daemon, rmid

By default, rmid now requires a security policy file.

*As used on this web site, the terms "Java virtual machine" or "JVM" mean a virtual machine for the Java platform.

Copyright © 2001 Sun Microsystems, Inc. All Rights Reserved.  Please send comments to: rmi-comments@java.sun.com