db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John H. Embretsen (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-3561) testStartStopManagementFromApplication(org.apache.derbyTesting.functionTests.tests.management.ManagementMBeanTest)junit.framework.AssertionFailedError: expected:<2> but was:<5>
Date Tue, 01 Apr 2008 14:36:25 GMT

     [ 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.


Mime
View raw message