[
https://issues.apache.org/jira/browse/DERBY-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John H. Embretsen updated DERBY-3561:
-------------------------------------
Attachment: Derby3561ReproStandalone.java
Derby3561ReproSuite_notForCommit.diff
I have done some more experimenting, and here is a writeup of my current
understanding of this issue:
As previously mentioned, I have narrowed down the test suite leading to
this failure to the following (test order is significant):
- derbynet.NSinSameJVMTest.suite()
- derbynet.ServerPropertiesTest.suite()
- management.ManagementMBeanTest.suite()
I have attached the minimal JUnit test suite (new java testclass) required
to reproduce this failure as a diff file against trunk:
Derby3561ReproSuite_notForCommit.diff (not for commit)
Some points to be aware of:
- Starting a Derby system in a 1.5 or 1.6 VM automatically results in
3 MBeans being registered. (If a security manager is installed,
sufficient permissions must be granted to Derby). Stopping the Derby
system means that the entire collection of Derby MBeans will be
attempted unregistered from the MBean server.
- Starting the Derby Network Server in a 1.5 or 1.6 VM automatically
results in 2 extra MBeans being registered, specific to the network
server. (If a security manager is installed, sufficient permissions must
be granted to Derby). Stopping the network server unregisters these
MBeans.
- Starting the network server results in starting a Derby system, if such
a system is not already running in the JVM. Stopping the network server
using the NetworkServerControl API does *not* also shut down the Derby
system (by design, I presume).
- Stopping/deactivating Derby management using the ManagementMBean means
that all Derby MBeans that are registered with both the MBean server
and Derby's management service will be unregistered from the MBean
server, with the exception of any ManagementMBeans (which may be used to
re-register the other MBeans).
The sequence of events leading to the test failure is:
1. NSinSameJVMTest (could also be some other test which does similar things):
- A clientServer decorator starts a new network server and thus also
a Derby system ("system A") using the NetworkServerControl API (same
JVM).
- Security policy used: functionTests/util/derby_tests.policy
- Includes permissions to register and unregister MBeans, etc.
==> 5 MBeans from system A are automatically registered with the
JVM's MBean server. The test doesn't know and doesn't care.
- The network server is shut down using the same API, and the same
security policy.
==> 2 MBeans (VersionMBean;derbynet.jar + NetworkServerMBean) from
system A are automatically unregistered.
- The remaining 3 MBeans (JDBCMBean + ManagementMBean +
VersionMBean;derby.jar) are not network server specific and will
therefore remain registered until the Derby system shuts down, or
until some manual intervention is performed.
Neither the test nor the test harness shuts down the Derby system.
2. ServerPropertiesTest
- Derby system A is still running...
- is wrapped in a decorator which changes the security policy from the
default to a specific one: derbynet/ServerPropertiesTest.policy.
- No JMX permissions are included in this policy.
==> No new MBeans are registered when the test starts its own network
servers/systems, due to lack of permissions (no exceptions are
thrown; this is by design). The test is unaware and does not care.
- ttestSetPortPriority() method starts and stops Network Servers, and
(more importantly) it shuts down the current Derby system (twice)
during the test (for some static properties to take effect). System A
has now been shut down.
- Since the test does not have permissions to unregister any MBeans,
the three MBeans from system A will remain registered with the
MBean server. The test doesn't know and doesn't care.
3. ManagementMBeanTest
- testStartStopManagementFromApplication() test and method
startStopManagement(ObjectName mbean) is run twice:
- once using a direct connection to the platform MBean server in the
same JVM as the test. This fails.
- once using a JMX client connection to a "remote" MBean server /
network server (different JVM). This passes.
- the decorator for the failing test starts a Derby Network Server in
the same JVM, to ensure that all MBeans are automatically registered.
Let's call the Derby system being used "system B".
- The policy file used is functionTests/util/derby_tests.policy,
including permissions to register MBeans etc.
==> 5 MBeans from system B are automatically registered with the
JVM's MBean server. This is what the test expects.
- The test registers an extra MBean: An application controlled
ManagementMBean, which is used for starting and stopping Derby
management.
- The test counts the number of MBeans in the org.apache.derby domain
several times.
- After stopping management, the test expects to see exactly 2 MBeans:
The ManagementMBean controlled by the application/test, and the
ManagementMBean that was automatically registered/created by Derby.
- However, the 3 MBeans from system A still remain registered with the
MBean server, although these MBeans are not registered with the
current Derby management service (different system, different
management service).
- The test sees 3 + 2 = 5 MBeans, but expects to see 2. The test fails.
User impact:
------------------
In my opinion, it is not very likely that a user will experience such a
scenario, as it requires modifying (restricting) or installing a security
policy at runtime and booting and shutting down Derby systems at the right
(wrong) moments.
If a user should run into this, nothing bad can happen as far as I can see.
The user may observere MBeans belonging to a non-active Derby system, even
if Derby's management service is deactivated, but that is basically it.
By using JConsole and a standalone test class (attached) I see that the old
MBeans are available and may be accessed, and most attributes still have the
same values, although the SystemIdentifier (ManagementMBean) is empty and
ManagementActive will always remain false. The startManagement operation of
an old ManagementMBean does not change anything, but it does not report an
error either.
You can reproduce this outside of JUnit by using the attached class
Derby3561ReproStandalone.java (see code comments).
Solutions:
-----------------
If we are concerned about this, an alternative solution could have been for
the Derby management service to unregister not only MBeans registered with
itself, but also any other MBeans belonging to the derby domain. However,
this seems to defeat the purpose of the system identifier and DERBY-3466.
Based on this, I believe adding a permission allowing the
ServerPropertiesTest to unregister Derby MBeans is a solution that makes
sense in order to get this test to pass. Such a change is implemented by
the patch d3561_testPolicyFix.diff.
> testStartStopManagementFromApplication(org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest)junit.framework.AssertionFailedError:
> expected:<2> but was:<5>
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-3561
> URL: https://issues.apache.org/jira/browse/DERBY-3561
> Project: Derby
> Issue Type: Bug
> Components: Regression Test Failure
> Affects Versions: 10.5.0.0
> Reporter: Mike Matrigali
> Assignee: John H. Embretsen
> Attachments: d3561_testPolicyFix.diff, Derby3561ReproStandalone.java,
> Derby3561ReproSuite_notForCommit.diff
>
>
> The following test has been failing consistently in the tinderbox runs since
> about build 636714, unfortunately the run right before this build failed so
> it may be from that one.
> first tinderbox failure I could find:
> http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/636714-org.apache.derbyTesting.functionTests.suites.All_diff.txt
> most recent as of this report:
> http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/639156-org.apache.derbyTesting.functionTests.suites.All_diff.txt
> There was 1 failure:
> 1)
> testStartStopManagementFromApplication(org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest)junit.framework.AssertionFailedError:
> expected:<2> but was:<5>
> at
> org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest.startStopManagement(ManagementMBeanTest.java:86)
> at
> org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest.testStartStopManagementFromApplication(ManagementMBeanTest.java:56)
> 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)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
