Great! Glad you found a way to pass a random port through to the activated
objects.
Poking around further, I think it's possible to use rmid's registry for
everything (instead of having the test start up its own registry) and to pass
the port information through to the activated objects running in rmid
subprocesses via the -C option. However, that's more work, and we'll keep that
in mind for the future.
I've removed the extra call to ActivationLibrary.deactivate() from the top of
the run() method, since this reintroduced the race condition that might cause
the callback object not to be called.
I also added a few comments to explain the ordering requirements, and the
possibility of using RMID's registry.
Pushed:
http://hg.openjdk.java.net/jdk8/tl/jdk/rev/018e555a7a07
s'marks
On 7/27/12 12:59 PM, Darryl Mocek wrote:
Hi Stuart,
I've changed this fix back to using a random port for the RMI Registry. I set
the port as a property (and supplied the appropriate permissions) after the
random port is created and added it to the ActivationGroupDesc, which will get
passed as a property when the object is activated. I then get the property in
UnregisterGroup's run method. This test (really) passes with these changes.
Webrev can be found here: http://cr.openjdk.java.net/~dmocek/7186111/webrev.01
Darryl
On 07/27/2012 12: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
