Hi Darryl,
Please review the webrev here:
http://cr.openjdk.java.net/~smarks/reviews/7186111/webrev.0/
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
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
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.AccessControlContext.checkPermission(AccessControlContext.java:364)
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.
s'marks