JDK-4867792 : HelloImpl RMI server exits after a short time frame if no request
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.rmi
  • Affected Version: 1.4.1_02
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_8
  • CPU: generic
  • Submitted: 2003-05-21
  • Updated: 2003-05-21
  • Resolved: 2003-05-21
Related Reports
Duplicate :  
JDK-4425728 - rmi server closes the connection early
Description
(You can download the sample from,
http://java.sun.com/j2se/1.4.1/docs/guide/security/jsse/samples/index.html)
download the jssesample

the rmi sample.
Using 1.4.1_02
compiled java files
rmic HelloImpl
and started up the rmiregistry
Using this command line
Java/jdk1.4.1_02/bin/java -Djava.security.policy="policy" -Djavax.net.ssl.trustStore="%~dp0testkeys" -Djavax.net.ssl.trustStorePassword=testkeys -Djava.rmi.server.codebase="file:/Java/ALI/RMI/jssesamples/rmi/" -Djava.rmi.server.logcalls=true HelloImpl

I get what I expect
HelloServer bound in registry

now if nothing is done the process exits.
Trussing looks like a SIGUSR1 was issue and shortly thereafter the exit()

It is my understanding that the server should stay up and running waiting for connections.

I tried one connection from the client succesfully and the server still halts.

This is not the expected bahavior.  Either a bug or something that was done incorrectly or this need to be documented behavior.

Also started up rmid just in case but that didn't have an effect.

this is a major concern as we don't feel this is the proper behavior for the server.
Comments
EVALUATION Regarding the 2006-04-18 JDC/SDN comment: The author says that the problem "only just began happening sometime between April 7th and April 11th" and "We're using the 1.5_06 VM on Sun Solaris. There was no change to the RMI server program code between the time that it was working, and when the problem began." What is not clear is, did the JRE/JDK versions in use changed during that period? Also, the Evaluation of 4425728 is indeed currently obscured, unfortunately, but here is an excerpt of the relevant text explaining why the JSSE RMI example had this problem in releases prior to 5.0: ============ The server VM terminates because there are no non-daemon threads running because the remote object gets garbage collected-- the RMI runtime maintains its own non-daemon thread in the background while there are any remote objects exported, but after none remain exported, there are no other non-daemon threads in this application (the main thread terminates after binding the remote object in the registry. So why does the remote object get garbage collected? After the "main" method terminates, the application has no local references to the remote object to keep it locally reachable. A binding in the registry normally keeps a remote object reachable through DGC (distributed GC), because the rmiregistry implementation holds its bindings with live remote references. Without the use of the custom socket factories, this works as expected. With the use of custom socket factories, however, the DGC communication that the registry must undertake to tell the HelloImpl VM that it is holding a live remote reference must go through the client socket factory, which is application code (not in boot class path). This code will be on the stack when the DGC communication is made, so it needs to be granted sufficient permissions to make that communication (SocketPermission "connect", at least). If the custom socket factory code were downloaded from an HTTP server on the same host as the remote object, then it would automatically be granted the necessary "connect" SocketPermission, but as this code is loaded from the rmiregistry's class path here, such permissions must be granted in the rmiregistry's policy (which it appears that you are not setting). So solutions include: - grant the necessary permissions to the socket factory code in the rmiregistry's security policy - let the rmiregistry's DGC communication fail and just hold a strong local reference to the remote object in a thread or static variable - arrange for the socket factory code to be downloadable from an HTTP server and use RMI's dynamic class loading functionality (and put stub class there too while you're at it) ================ Note that the solution actually undertaken for 4425728, to "fix" the JSSE RMI example for the JDK 5.0 documentation bundle, was to bind the remote object in a registry created in the same VM as the remote object (created using the LocateRegistry.createRegistry API). Here is the code: http://java.sun.com/j2se/1.5.0/docs/guide/security/jsse/samples/rmi/HelloImpl.java Because a reference to the HelloImpl remote object itself (not a remote stub for it) is passed directly to a reference to the registry's remote object (not a stub for it), this works because a strong reference to the remote object will be held directly by the registry (the non-remote invocation does not cause the HelloImpl remote object to be replaced with its stub). If, alternatively, the registry invocation had been on a registry stub (obtained from LocateRegistry.getRegistry), then this would have also solved the problem, because the registry would be running in a VM whose policy file already grants the appropriate permissions to the socket factory classes, so the DGC communication would be able to succeed. [Another seemingly-plausibile alternative of passing the result of RemoteObject.toStub or UnicastRemoteObject.exportObject to a non-remote invocation of the registry, i.e. to an invocation of the reference returned by LocateRegistry.createRegistry instead of LocateRegistry.getRegistry, would likely have still had a premature garbage collection problem because of 4114579.]
19-04-2006
EVALUATION This reason for the described behavior is explained in the Evaluation for 4425728. In summary, the registry VM's security policy file should grant the client socket factory code "connect" SocketPermission to make DGC communication back to the server-- or the server code could make sure that the remote object does not get garbage collected, by keeping a strong reference to it in a live thread. The documentation for this JSSE/RMI example should be updated to address this issue. I'm marking this bug as a duplicate of 4425728, which represents such an update. Also see: http://archives.java.sun.com/cgi-bin/wa?A2=ind0303&L=rmi-users&P=R2714 ###@###.### 2003-05-21
21-05-2003