Performance Issues

The following sections are areas where WebLogic's implementation of RMI has reportedly demonstrated marked enhancements in performance over generic RMI implementations.

Scalability

Scaling for RMI clients is linear. The WebLogic Server implementation of RMI, running on a small, single-processor, PC-class server can reportedly support more than 1,000 simultaneous RMI clients. If true, this is a marked improvement on the basic JavaSoft RMI implementation. See http://e-docs.bea.com/wls/docs81/rmi/rmi_intro.html#852658.

Thread/Socket Management

WebLogic RMI requests can be divided into a determinant number of threads. Multithread processing allows exploitation of latency times and available processors. WebLogic's implementation of RMI uses a single, bi-directional, asynchronous connection. WebLogic Server provides the connection; the client does not listen for connections, and there are no client server sockets. The same connection is also used for JDBC and other services, thereby reducing server overhead.

Serialization

WebLogic RMI uses greatly enhanced high-performance serialization, offering a performance gain even for one-time remote class use. WebLogic implements the Externalizable interface rather than the Serializable interface used in generic RMI implementation. This option saves overhead in the serialization process; that is, no super classes are serialized. The use of WebLogic's T3 protocol and a single asynchronous bi-directional connection in the serialization process also contributes to performance gains.

Supporting Services

WebLogic RMI uses WebLogic Registry services and WebLogic JNDI; both yield higher efficiencies than the generic versions. WebLogic's flavor of Java garbage collection is also optimized. WebLogic's T3 protocol greatly optimizes communications between remote components.

Distributed Garbage Collection

The distributed garbage collection mechanism, based on the Modula-3 Network Objects, works by requiring the server to track clients requesting the RMI. References to requested objects are flagged as dirty when the object is requested. The flag is removed (flagged as clean) when the client drops the reference and the object is eligible for server-side garbage collection. The client reference to the RMI object also has a lease. If the client does not refresh the remote object within the time limit of the lease, the object is then also eligible for server-side garbage collection.

The distributed garbage collection interface is java.rmi.server.Unreferenced. Implementing this interface provides notification when all clients have dropped references to the remote object. As mentioned earlier, due to the nature of distributed garbage collection, developers should code RMI clients to deal with the situation in which the server-side lease has expired while the clients still requires use of the remote object. WebLogic optimizes garbage collection by providing an option of implementing the Java HotSpot Server VM as opposed to the Java HotSpot Client or Classic Java VM(s). The Server version of the HotSpot VM provides for the fastest possible (long run) operating times that enhances garbage collection, as opposed to faster application startup times with slower operating times. This option is activated by passing the -server option at WebLogic Server startup.