RFR: 7186111 fix test java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup
Jim Gish
jim.gish at oracle.com
Fri Jul 27 14:54:03 UTC 2012
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.gish at oracle.com
More information about the core-libs-dev
mailing list