Hi Stuart,
The code looks fine. Personally, I would like to see some of your
explanation below end up as comments in the code, so that subsequent
readers/modifiers of the code understand why it's done the way it is, in
particular why we are now using a fixed port instead of a random port
and what are the unanswered questions in reintroducing a random port if
someone wants to try giving it a shot in the future.
Thanks,
Jim
On 07/27/2012 03:26 AM, Stuart Marks wrote:
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
--
Jim Gish | Consulting Member of Technical Staff | +1.781.442.0304
Oracle Java Platform Group | Core Libraries Team
35 Network Drive
Burlington, MA 01803
jim.g...@oracle.com
