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

[Jim Gish]

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