RFR: 7186111 fix test java/rmi/activation/ActivationSystem/unregisterGroup/UnregisterGroup
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
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@oracle.com
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
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
participants (3)
-
Darryl Mocek
-
Jim Gish
-
Stuart Marks