Description

suitesAll fail *************************************************************
1) testDerbynetJarAttributeAlpha(org.apache.derbyTesting.functionTests.tests.management.VersionMBeanTest)java.security.PrivilegedActionException: javax.management.InstanceNotFoundException: org.apache.derby:type=Version,system=c013800d-011a-02c6-d312-0000600c993a,jar=derbynet.jar
suitesAll fail *************************************************************
.........................................
.
.
.........................................
.............................
Time: 8,078.973
There was 1 error:
1) testDerbynetJarAttributeAlpha(org.apache.derbyTesting.functionTests.tests.management.VersionMBeanTest)java.security.PrivilegedActionException: javax.management.InstanceNotFoundException: org.apache.derby:type=Version,system=c013800d-011a-02c6-d312-0000600c993a,jar=derbynet.jar
at java.security.AccessController.doPrivileged(Native Method)
at org.apache.derbyTesting.functionTests.tests.management.MBeanTest.getAttribute(MBeanTest.java:379)
at org.apache.derbyTesting.functionTests.tests.management.MBeanTest.checkBooleanAttributeValue(MBeanTest.java:431)
at org.apache.derbyTesting.functionTests.tests.management.VersionMBeanTest.testDerbynetJarAttributeAlpha(VersionMBeanTest.java:124)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:101)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
at junit.extensions.TestSetup.run(TestSetup.java:25)
at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
Caused by: javax.management.InstanceNotFoundException: org.apache.derby:type=Version,system=c013800d-011a-02c6-d312-0000600c993a,jar=derbynet.jar
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1094)
at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:662)
at com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:638)
at org.apache.derbyTesting.functionTests.tests.management.MBeanTest$4.run(MBeanTest.java:382)
... 42 more

I think I see how this could be happening. NetworkServerControlImpl.blockingStart() starts the ClientThread that accepts incoming connections before it registers the MBeans. This means the server will give the impression of being up (that is, it's answering ping requests) before the MBeans are ready. The tests typically start once the server answers ping, and may therefore start accessing the MBeans too early.

Knut Anders Hatlen
added a comment - 17/Apr/11 19:40 I think I see how this could be happening. NetworkServerControlImpl.blockingStart() starts the ClientThread that accepts incoming connections before it registers the MBeans. This means the server will give the impression of being up (that is, it's answering ping requests) before the MBeans are ready. The tests typically start once the server answers ping, and may therefore start accessing the MBeans too early.

Adding Thread.sleep(1000) after clientThread.start() in NetworkServerControlImpl.blockingStart() makes this failure reproduce reliably. I'm not sure if this is a server bug, or if it's just a test bug. One might imagine fixing it by making the test framework ping the JMX functionality until it's up before starting the test, similar to what it does to give the network server time to start. But changing the order of the startup to make it more test friendly sounds like an easy enough solution, and I cannot see that registering the MBeans before we start accepting connections should cause any problems, so I'll make an attempt on that approach.

Knut Anders Hatlen
added a comment - 16/Jun/11 13:31 Adding Thread.sleep(1000) after clientThread.start() in NetworkServerControlImpl.blockingStart() makes this failure reproduce reliably. I'm not sure if this is a server bug, or if it's just a test bug. One might imagine fixing it by making the test framework ping the JMX functionality until it's up before starting the test, similar to what it does to give the network server time to start. But changing the order of the startup to make it more test friendly sounds like an easy enough solution, and I cannot see that registering the MBeans before we start accepting connections should cause any problems, so I'll make an attempt on that approach.

Here's a patch that makes the network server register the MBeans before it starts accepting connections from the client. Since the test framework makes sure the tests don't start until the network server accepts connections, this reordering ensures that the MBeans are registered and ready for testing when the test starts.

All the regression tests ran cleanly with the patch in my environment.

Knut Anders Hatlen
added a comment - 17/Jun/11 09:40 Here's a patch that makes the network server register the MBeans before it starts accepting connections from the client. Since the test framework makes sure the tests don't start until the network server accepts connections, this reordering ensures that the MBeans are registered and ready for testing when the test starts.
All the regression tests ran cleanly with the patch in my environment.