RFR: 7186111 fix test java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup

Stuart Marks stuart.marks at oracle.com
Fri Jul 27 07:26:31 UTC 2012

Hi Darryl,

Please review the webrev here:


which should fix the problems in the UnregisterGroup test. The permissions 
adjustment you had sent doesn't fix the test; it still passes, but it was still 
dysfunctional. Given that the SQE folks have been complaining that this test 
has been hanging their system, I decided to dig into it.

Explanation follows.

As things stand prior to this change, the test run has this 
AccessControlException stack trace in it:

     java.lang.RuntimeException: Error getting registry port.
	at TestLibrary.getRegistryPort(TestLibrary.java:394)
	at UnregisterGroup.main(UnregisterGroup.java:239)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at java.lang.reflect.Method.invoke(Method.java:474)
	at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
	at java.lang.Thread.run(Thread.java:722)
     Caused by: java.security.AccessControlException: access denied 
("java.lang.RuntimePermission" "accessClassInPackage.sun.rmi.registry")
	at java.security.AccessController.checkPermission(AccessController.java:555)
	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
	at java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1529)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:305)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
	at TestLibrary.getRegistryPort(TestLibrary.java:388)
	... 7 more

You had sent me some permissions changes that we thought would fix this bug. 
Indeed, they clear up the access control problem. But the test still had some 
additional errors, and these weren't cleared up by adjusting the permissions:

     java.net.MalformedURLException: invalid authority: //:-1/Callback
	at java.rmi.Naming.intParseURL(Naming.java:326)
	at java.rmi.Naming.parseURL(Naming.java:237)
	at java.rmi.Naming.lookup(Naming.java:96)
	at UnregisterGroup.run(UnregisterGroup.java:119)
	at java.lang.Thread.run(Thread.java:722)

The problem here is that we're creating a registry on a random port, and (with 
the permissions adjustment) we're successfully getting the port number out of 
it. But the port in the URL is still -1?? Well, that's because the code 
attempting to contact the registry is an Activatable object which is running in 
a different JVM. So we can't get the random registry port over to it.

I pulled out the random port stuff (and the corresponding permissions) and had 
this test use a reserved port for the registry. (At some point we might want to 
consider trying to use a random port, but we have to pass this all the way from 
the test program through rmid into the activated objects, and I don't know how 
to do that.)

The next problem was that I got intermittent "connection refused" messages when 
the activated objects were trying to look up the Callback object. The problem 
there was that the test program activated the objects and *then* created its 
registry, causing a race condition where the activated objects might attempt to 
contact the registry before it was created. Creating the registry up front 
fixed that.

The next problem was that the activated objects would usually not end up 
calling the Callback object. This occurred because when the object deactivated 
itself, it would kill the JVM containing the activated object. Thus the call to 
the Callback might not complete. The fix here is to call the Callback before 
deactivating the object. Now that the callbacks are reliable, the main test 
program doesn't wait around for 30 seconds for callbacks that won't occur, and 
it now runs in about 3 seconds instead.

After all that, the code and the changes are actually pretty simple.


More information about the core-libs-dev mailing list