Derby
  1. Derby
  2. DERBY-4249

Create a simple store recovery test in JUnit

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 10.6.1.0
    • Fix Version/s: 10.9.1.0
    • Component/s: Test
    • Labels:
      None

      Description

      It would be good to be able to start converting the store recovery tests or at least be able to write new recovery tests in JUnit. We could start by writing a simple recovery test just to establish the framework. The test should.

      • Connect, create a table, commit and shutdown the database.
      • fork a jvm, add one row, commit, add another row, exit the jvm.
      • Reconnect with the first jvm and verify that the first row is there and the second is not.

      I guess the main thing to decide is how to spawn the second jvm and check results. I tend to think the second jvm should actually execute another JUnit test, verify the exit code (assuming a failed test has a non-zero exit code) and then put the output in the fail assertion if it fails so it shows up in the report at the end of the Suite execution. I think we could create a test runner that takes a class and a specific test to run instead of the whole suite, so we could keep our methods consolidated in a single class for the test, but all pure conjecture at this point. I'll have to give it a try, but wanted to first see if folks thought this was a reasonable approach.

      1. derby4249_showlaunchederr_diff.txt
        2 kB
        Kathey Marsden
      2. derby4249_secmgr_diff.txt
        9 kB
        Kathey Marsden
      3. derby4249.diff
        7 kB
        Siddharth Srivastava
      4. derby4249.diff
        7 kB
        Siddharth Srivastava
      5. d4249_3.diff
        8 kB
        Siddharth Srivastava
      6. d4249_2.diff
        8 kB
        Siddharth Srivastava
      7. d4249_1.diff
        9 kB
        Siddharth Srivastava
      8. d4249.diff
        3 kB
        Siddharth Srivastava

        Issue Links

          Activity

          Kathey Marsden created issue -
          Hide
          Siddharth Srivastava added a comment -

          Hi Kathey

          Can you please assign this issue to me ?

          Are there any recommended tests which I should study/look upon as a reference to understand things better ?

          Show
          Siddharth Srivastava added a comment - Hi Kathey Can you please assign this issue to me ? Are there any recommended tests which I should study/look upon as a reference to understand things better ?
          Kathey Marsden made changes -
          Field Original Value New Value
          Assignee Kathey Marsden [ kmarsden ] Siddharth Srivastava [ siddharthsrivastava ]
          Siddharth Srivastava made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          Siddharth Srivastava made changes -
          Status In Progress [ 3 ] Open [ 1 ]
          Siddharth Srivastava made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          Hide
          Kathey Marsden added a comment -

          I think ultimately we are going to want have a fixture that launches a jvm to run another fixture that lives in the same class. So, perhaps the best way to start would be by making a command line test runner that will run a single fixture in embedded mode. It might be run something like:

          java org.apache.derbyTesting.functionTests.util.SingleFixtureRunner <test class> <fixture name>

          e.g.
          java org.apache.derbyTesting.functionTests.util.SingleFixtureRunner org.apache.derbyTesting.functionTests.tests.lang.SimpleTest testBugFixes

          I think this would be a useful tool in and of itself and is something we can use for the recover test. At least for the initial version it will be just straight embedded with no decorators.

          The code would have to use reflection to kick off the fixture and on error could just print the error info and stack trace to System.err. It might look something like this (totally untested and printFailInfo left as exercise).

          String testClassName = args[0];
          String fixtureName = args[1];
          Class testClass = Class.forName(testClassName);
          Constructor classConstr = testClass.getDeclaredConstructor(new Class[]

          {String.class}

          );
          Test testToRun = (Test) classConstr.newInstance(new Object[]

          {fixtureName}

          );
          TestResult result = new TestResult();
          testToRun.run(result);
          if (result.wasSuccessful())
          return;
          if (result.failureCount() > 0)
          printFailInfo(result.failures());
          if (result.errorCount() > 0)
          printFailInfo(result.errors());
          System.exit(-1);

          If you get that done, then next we can add an assertLaunchJunitFixture() method to BaseTestCase which prints the error output to System.err if the launch fails. Then we should have all the parts we need for the basic recovery test.

          Show
          Kathey Marsden added a comment - I think ultimately we are going to want have a fixture that launches a jvm to run another fixture that lives in the same class. So, perhaps the best way to start would be by making a command line test runner that will run a single fixture in embedded mode. It might be run something like: java org.apache.derbyTesting.functionTests.util.SingleFixtureRunner <test class> <fixture name> e.g. java org.apache.derbyTesting.functionTests.util.SingleFixtureRunner org.apache.derbyTesting.functionTests.tests.lang.SimpleTest testBugFixes I think this would be a useful tool in and of itself and is something we can use for the recover test. At least for the initial version it will be just straight embedded with no decorators. The code would have to use reflection to kick off the fixture and on error could just print the error info and stack trace to System.err. It might look something like this (totally untested and printFailInfo left as exercise). String testClassName = args [0] ; String fixtureName = args [1] ; Class testClass = Class.forName(testClassName); Constructor classConstr = testClass.getDeclaredConstructor(new Class[] {String.class} ); Test testToRun = (Test) classConstr.newInstance(new Object[] {fixtureName} ); TestResult result = new TestResult(); testToRun.run(result); if (result.wasSuccessful()) return; if (result.failureCount() > 0) printFailInfo(result.failures()); if (result.errorCount() > 0) printFailInfo(result.errors()); System.exit(-1); If you get that done, then next we can add an assertLaunchJunitFixture() method to BaseTestCase which prints the error output to System.err if the launch fails. Then we should have all the parts we need for the basic recovery test.
          Hide
          Siddharth Srivastava added a comment -

          Thanks Kathey.
          I have attached the patch for SingleFixtureRunner.

          Show
          Siddharth Srivastava added a comment - Thanks Kathey. I have attached the patch for SingleFixtureRunner.
          Siddharth Srivastava made changes -
          Attachment d4249.diff [ 12486004 ]
          Hide
          Knut Anders Hatlen added a comment -

          I think junit.textui.TestRunner can do the same with the -m option:

          java junit.textui.TestRunner -m <classname>.<methodname>

          Show
          Knut Anders Hatlen added a comment - I think junit.textui.TestRunner can do the same with the -m option: java junit.textui.TestRunner -m <classname>.<methodname>
          Hide
          Kathey Marsden added a comment -

          Thanks Knut, that sounds neat, but doesn't seem to work for me.
          $ java junit.textui.TestRunner -m org.apache.derbyTesting.functionTests.tests.
          ang.SimpleTest.testBugFixes
          Class not found "org.apache.derbyTesting.functionTests.tests.lang.SimpleTest.testBugFixes"

          Nor do I see it in the javadoc
          http://junit.sourceforge.net/junit3.8.1/javadoc/junit/textui/TestRunner.html

          What might I be doing wrong?

          Show
          Kathey Marsden added a comment - Thanks Knut, that sounds neat, but doesn't seem to work for me. $ java junit.textui.TestRunner -m org.apache.derbyTesting.functionTests.tests. ang.SimpleTest.testBugFixes Class not found "org.apache.derbyTesting.functionTests.tests.lang.SimpleTest.testBugFixes" Nor do I see it in the javadoc http://junit.sourceforge.net/junit3.8.1/javadoc/junit/textui/TestRunner.html What might I be doing wrong?
          Hide
          Knut Anders Hatlen added a comment -

          The -m command line option was added in JUnit 3.8.2, so it won't work with 3.8.1. (3.8.2 is the version we tell people to download in BUILDING.html, by the way.) There used to be problems with running the Java ME tests on 3.8.2 (according to http://wiki.apache.org/db-derby/JunitVmIssues) but they seem to affect Foundation 1.0 only, which we don't support anymore. So hopefully a dependency on 3.8.2 would be fine these days.

          Show
          Knut Anders Hatlen added a comment - The -m command line option was added in JUnit 3.8.2, so it won't work with 3.8.1. (3.8.2 is the version we tell people to download in BUILDING.html, by the way.) There used to be problems with running the Java ME tests on 3.8.2 (according to http://wiki.apache.org/db-derby/JunitVmIssues ) but they seem to affect Foundation 1.0 only, which we don't support anymore. So hopefully a dependency on 3.8.2 would be fine these days.
          Hide
          Siddharth Srivastava added a comment -

          I trying to fork the JVM and insert rows into the database. But the test fails:
          There was 1 failure:
          ------------------------------------------------------------------------------------
          1) testBasicRecovery(org.apache.derbyTesting.functionTests.tests.store.RecoveryT
          est)junit.framework.AssertionFailedError: Unexpected row count: expected:<1> but
          was:<0>
          at org.apache.derbyTesting.junit.JDBC.assertFullResultSetMinion(JDBC.jav
          a:1020)
          at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:935)

          at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:892)

          at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:850)

          at org.apache.derbyTesting.functionTests.tests.store.RecoveryTest.assert
          Database(RecoveryTest.java:78)
          at org.apache.derbyTesting.functionTests.tests.store.RecoveryTest.testBa
          sicRecovery(RecoveryTest.java:58)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
          at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:
          113)
          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)

          FAILURES!!!
          Tests run: 1, Failures: 1, Errors: 0
          -------------------------------------------------------------------------------------

          It seems that launchRecoveryInsert() isn't executed at all.
          Also if I check exitValue(), the assertLaunchedJUnitFixture generates a IllegalThreadStateException.

          What am I doing wrong ?

          Note: Please ignore some commented out and ugly looking code(and functions) in the diff

          Show
          Siddharth Srivastava added a comment - I trying to fork the JVM and insert rows into the database. But the test fails: There was 1 failure: ------------------------------------------------------------------------------------ 1) testBasicRecovery(org.apache.derbyTesting.functionTests.tests.store.RecoveryT est)junit.framework.AssertionFailedError: Unexpected row count: expected:<1> but was:<0> at org.apache.derbyTesting.junit.JDBC.assertFullResultSetMinion(JDBC.jav a:1020) at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:935) at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:892) at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:850) at org.apache.derbyTesting.functionTests.tests.store.RecoveryTest.assert Database(RecoveryTest.java:78) at org.apache.derbyTesting.functionTests.tests.store.RecoveryTest.testBa sicRecovery(RecoveryTest.java:58) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java: 113) 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) FAILURES!!! Tests run: 1, Failures: 1, Errors: 0 ------------------------------------------------------------------------------------- It seems that launchRecoveryInsert() isn't executed at all. Also if I check exitValue(), the assertLaunchedJUnitFixture generates a IllegalThreadStateException. What am I doing wrong ? Note: Please ignore some commented out and ugly looking code(and functions) in the diff
          Siddharth Srivastava made changes -
          Attachment d4249_1.diff [ 12486736 ]
          Hide
          Kathey Marsden added a comment -

          Hi Siddharth,

          I did not apply but looked briefly at why the process might not execute.
          String[] cmd= new String[]

          {"java junit.textui.TestRunner -m org.apache.derbyTesting.functionTests.tests.store.RecoveryTest.launchRecoveryInsert"}

          ;

          The individual arguments should be broken out into separate String array elements and also java should not be included in what is passed to execJavaCmd as the java executable is determined by execJavaCmd. I'd suggest you make that change and then run the test with -Dderby.tests.debug=true and then execJavaCmd will show exactly what it is trying to execute. You can then cut and paste that into a shell to see what might be going wrong. You can also use BaseTestCase.readProcessOutput to read the output and see what error is being encountered. This method will probably be useful as well to get the output if the process fails.

          As an aside, ultimately you will want to pass the class and fixture into assertLaunchedJUnitFixture() so it can be used generically.

          Show
          Kathey Marsden added a comment - Hi Siddharth, I did not apply but looked briefly at why the process might not execute. String[] cmd= new String[] {"java junit.textui.TestRunner -m org.apache.derbyTesting.functionTests.tests.store.RecoveryTest.launchRecoveryInsert"} ; The individual arguments should be broken out into separate String array elements and also java should not be included in what is passed to execJavaCmd as the java executable is determined by execJavaCmd. I'd suggest you make that change and then run the test with -Dderby.tests.debug=true and then execJavaCmd will show exactly what it is trying to execute. You can then cut and paste that into a shell to see what might be going wrong. You can also use BaseTestCase.readProcessOutput to read the output and see what error is being encountered. This method will probably be useful as well to get the output if the process fails. As an aside, ultimately you will want to pass the class and fixture into assertLaunchedJUnitFixture() so it can be used generically.
          Hide
          Siddharth Srivastava added a comment -

          Attached is the patch for this issue.Any suggestions/improvements would be nice.

          Show
          Siddharth Srivastava added a comment - Attached is the patch for this issue.Any suggestions/improvements would be nice.
          Siddharth Srivastava made changes -
          Attachment d4249_2.diff [ 12487472 ]
          Hide
          Siddharth Srivastava added a comment -

          Sorry, mistakenly uploaded wrong patch earlier. This is the latest one.

          Show
          Siddharth Srivastava added a comment - Sorry, mistakenly uploaded wrong patch earlier. This is the latest one.
          Siddharth Srivastava made changes -
          Attachment d4249_3.diff [ 12487476 ]
          Hide
          Dag H. Wanvik added a comment -

          I tried to let the nested VM exit with a System.exit(1) but the top level test still passed. I guess the top level test should discover if its child exited with anything but clean status?

          Should the nested system out from running the JUnit be visible on the top level System.out by default? It could get confusing as we add more fixtures what belongs to what level...

          Another question, the way the nested VM's database is stopped now, we do get a checkpoint performed, although the transaction is not rolled back (I checked the log file with Rick's LogFileReader and saw a checkpoint operation, but no logical undo). Is this the way it happens in the old recovery tests or do they not lead to checkpoints?

          Show
          Dag H. Wanvik added a comment - I tried to let the nested VM exit with a System.exit(1) but the top level test still passed. I guess the top level test should discover if its child exited with anything but clean status? Should the nested system out from running the JUnit be visible on the top level System.out by default? It could get confusing as we add more fixtures what belongs to what level... Another question, the way the nested VM's database is stopped now, we do get a checkpoint performed, although the transaction is not rolled back (I checked the log file with Rick's LogFileReader and saw a checkpoint operation, but no logical undo). Is this the way it happens in the old recovery tests or do they not lead to checkpoints?
          Hide
          Knut Anders Hatlen added a comment -

          Some comments in addition to what Dag said:

          • On the terminology: My understanding is that "fixture" refers to the fixed state created by the setUp() method, so it's not something one can launch. It would probably be clearer to call the method something like "assertLaunchedJUnitTestMethod".
          • I think the assert method should throw any exceptions it encounters, not catch them and print them.
          • Perhaps we could take advantage of the existing assertExecJavaCmdAsExpected() method? That method checks both the exit status and the presence of expected strings in the output, and it only prints the output from the nested test if it's not what we expected, so it would probably address Dag's first two comments. Something like this might work:

          String[] cmd = new String[]

          { "junit.textui.TestRunner", "-m", testMethod }

          ;
          assertExecJavaCmdAsExpected(new String[]

          { "OK (1 test)" }

          , cmd, 0);

          Show
          Knut Anders Hatlen added a comment - Some comments in addition to what Dag said: On the terminology: My understanding is that "fixture" refers to the fixed state created by the setUp() method, so it's not something one can launch. It would probably be clearer to call the method something like "assertLaunchedJUnitTestMethod". I think the assert method should throw any exceptions it encounters, not catch them and print them. Perhaps we could take advantage of the existing assertExecJavaCmdAsExpected() method? That method checks both the exit status and the presence of expected strings in the output, and it only prints the output from the nested test if it's not what we expected, so it would probably address Dag's first two comments. Something like this might work: String[] cmd = new String[] { "junit.textui.TestRunner", "-m", testMethod } ; assertExecJavaCmdAsExpected(new String[] { "OK (1 test)" } , cmd, 0);
          Hide
          Kathey Marsden added a comment -

          I agree that the test should definitely fail if the launched test method fails. It sounds good to use assertExecJavaCmdAsExpected. It would be good to enhace that method on failure to in the fail message to include full error output so we get the stack trace of the failed method.

          On the test itself I think it would actually be good to inline createBasicSetup() and assertDatabase() into testBasicRecovery() method and also add javadoc comments about the purpose of the test in order to provide some context of what we are testing here and also reduce clutter if more fixtures are added.

          I think the reason we are seeing the checkpoint is that launchRecoveryInsert is shutting down the database which it should not. It should just insert /commit/insert /return. I would not even close the statement and connection here and as mentioned before just let the errors be thrown in all cases so the test will fail. Typically the only time in a JUnit test that we need a try/catch is when it is a negative test and we are expecting an exception and then there would be a fail before the catch and then an assertSQLState() or some such to verify we got the right exception. Bottom line is for JUnit the pass or fail state of the test should be an assertion, not the printed output.

          Why does the test need to run without security manager? Security Manager should be on unless there is a good reason for it to be off.

          One nit. The class name at the top of the license header should be the full class name.

          On another note if you want to print output for debug purposes and think it might be useful to others in the future debugging failures you can just use println instead of System.out.println and then run with -Dderby.tests.debug=true

          Thank you Siddharth for your work on this important test and framework for the recovery tests. I'll be out for a few weeks starting Thursday. I appreciate the community continuing to look at the patch revisions while I am out.

          Show
          Kathey Marsden added a comment - I agree that the test should definitely fail if the launched test method fails. It sounds good to use assertExecJavaCmdAsExpected. It would be good to enhace that method on failure to in the fail message to include full error output so we get the stack trace of the failed method. On the test itself I think it would actually be good to inline createBasicSetup() and assertDatabase() into testBasicRecovery() method and also add javadoc comments about the purpose of the test in order to provide some context of what we are testing here and also reduce clutter if more fixtures are added. I think the reason we are seeing the checkpoint is that launchRecoveryInsert is shutting down the database which it should not. It should just insert /commit/insert /return. I would not even close the statement and connection here and as mentioned before just let the errors be thrown in all cases so the test will fail. Typically the only time in a JUnit test that we need a try/catch is when it is a negative test and we are expecting an exception and then there would be a fail before the catch and then an assertSQLState() or some such to verify we got the right exception. Bottom line is for JUnit the pass or fail state of the test should be an assertion, not the printed output. Why does the test need to run without security manager? Security Manager should be on unless there is a good reason for it to be off. One nit. The class name at the top of the license header should be the full class name. On another note if you want to print output for debug purposes and think it might be useful to others in the future debugging failures you can just use println instead of System.out.println and then run with -Dderby.tests.debug=true Thank you Siddharth for your work on this important test and framework for the recovery tests. I'll be out for a few weeks starting Thursday. I appreciate the community continuing to look at the patch revisions while I am out.
          Hide
          Siddharth Srivastava added a comment -

          Hi

          Thanks for your suggestions Dag, Knut, Kathey.
          I have incorporated all the suggestions

          As far as Security Manager is concerned, I expected a FilePermissions issue. Without disabling the security issue, following error is thrown:

          .java.security.AccessControlException: access denied (java.io.FilePermission C:\
          Program Files\Java\jre6\bin\java execute)
          at java.security.AccessControlContext.checkPermission(Unknown Source)
          at java.security.AccessController.checkPermission(Unknown Source)
          at java.lang.SecurityManager.checkPermission(Unknown Source)
          at java.lang.SecurityManager.checkExec(Unknown Source)
          at java.lang.ProcessBuilder.start(Unknown Source)
          at java.lang.Runtime.exec(Unknown Source)
          at java.lang.Runtime.exec(Unknown Source)
          at org.apache.derbyTesting.junit.BaseTestCase$8.run(BaseTestCase.java:56
          6)
          at java.security.AccessController.doPrivileged(Native Method)
          at org.apache.derbyTesting.junit.BaseTestCase.execJavaCmd(BaseTestCase.j
          ava:562)
          at org.apache.derbyTesting.junit.BaseTestCase.assertLaunchedJUnitFixture
          (BaseTestCase.java:832)
          at org.apache.derbyTesting.functionTests.tests.store.RecoveryTest.testBa
          sicRecovery(RecoveryTest.java:67)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
          at java.lang.reflect.Method.invoke(Unknown Source)
          at junit.framework.TestCase.runTest(TestCase.java:164)
          at junit.framework.TestCase.runBare(TestCase.java:130)
          at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:
          106)
          at junit.framework.TestResult$1.protect(TestResult.java:106)
          at junit.framework.TestResult.runProtected(TestResult.java:124)
          at junit.framework.TestResult.run(TestResult.java:109)
          at junit.framework.TestCase.run(TestCase.java:120)
          at junit.framework.TestSuite.runTest(TestSuite.java:230)
          at junit.framework.TestSuite.run(TestSuite.java:225)
          at junit.framework.TestSuite.runTest(TestSuite.java:230)
          at junit.framework.TestSuite.run(TestSuite.java:225)
          at junit.textui.TestRunner.doRun(TestRunner.java:121)
          at junit.textui.TestRunner.start(TestRunner.java:185)
          at junit.textui.TestRunner.main(TestRunner.java:143)
          F
          Time: 13.915
          There was 1 failure:
          1) testBasicRecovery(org.apache.derbyTesting.functionTests.tests.store.RecoveryT
          est)junit.framework.AssertionFailedError: Unexpected row count: expected:<1> but
          was:<0>
          at org.apache.derbyTesting.junit.JDBC.assertFullResultSetMinion(JDBC.jav
          a:1020)
          at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:935)

          at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:892)

          at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:850)

          at org.apache.derbyTesting.functionTests.tests.store.RecoveryTest.assert
          Database(RecoveryTest.java:111)
          at org.apache.derbyTesting.functionTests.tests.store.RecoveryTest.testBa
          sicRecovery(RecoveryTest.java:68)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
          at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:
          106)

          FAILURES!!!
          Tests run: 1, Failures: 1, Errors: 0

          I am executing it with Administrative privileges and have revoked read only permissions from the concerned java directory.
          So Is this issue faced only by me (hoping that my platform specific issues are not back again)

          Show
          Siddharth Srivastava added a comment - Hi Thanks for your suggestions Dag, Knut, Kathey. I have incorporated all the suggestions As far as Security Manager is concerned, I expected a FilePermissions issue. Without disabling the security issue, following error is thrown: .java.security.AccessControlException: access denied (java.io.FilePermission C:\ Program Files\Java\jre6\bin\java execute) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkExec(Unknown Source) at java.lang.ProcessBuilder.start(Unknown Source) at java.lang.Runtime.exec(Unknown Source) at java.lang.Runtime.exec(Unknown Source) at org.apache.derbyTesting.junit.BaseTestCase$8.run(BaseTestCase.java:56 6) at java.security.AccessController.doPrivileged(Native Method) at org.apache.derbyTesting.junit.BaseTestCase.execJavaCmd(BaseTestCase.j ava:562) at org.apache.derbyTesting.junit.BaseTestCase.assertLaunchedJUnitFixture (BaseTestCase.java:832) at org.apache.derbyTesting.functionTests.tests.store.RecoveryTest.testBa sicRecovery(RecoveryTest.java:67) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at junit.framework.TestCase.runTest(TestCase.java:164) at junit.framework.TestCase.runBare(TestCase.java:130) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java: 106) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at junit.textui.TestRunner.doRun(TestRunner.java:121) at junit.textui.TestRunner.start(TestRunner.java:185) at junit.textui.TestRunner.main(TestRunner.java:143) F Time: 13.915 There was 1 failure: 1) testBasicRecovery(org.apache.derbyTesting.functionTests.tests.store.RecoveryT est)junit.framework.AssertionFailedError: Unexpected row count: expected:<1> but was:<0> at org.apache.derbyTesting.junit.JDBC.assertFullResultSetMinion(JDBC.jav a:1020) at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:935) at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:892) at org.apache.derbyTesting.junit.JDBC.assertFullResultSet(JDBC.java:850) at org.apache.derbyTesting.functionTests.tests.store.RecoveryTest.assert Database(RecoveryTest.java:111) at org.apache.derbyTesting.functionTests.tests.store.RecoveryTest.testBa sicRecovery(RecoveryTest.java:68) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java: 106) FAILURES!!! Tests run: 1, Failures: 1, Errors: 0 I am executing it with Administrative privileges and have revoked read only permissions from the concerned java directory. So Is this issue faced only by me (hoping that my platform specific issues are not back again)
          Siddharth Srivastava made changes -
          Attachment derby4249.diff [ 12488307 ]
          Hide
          Siddharth Srivastava added a comment -

          Updated patch

          Show
          Siddharth Srivastava added a comment - Updated patch
          Siddharth Srivastava made changes -
          Attachment derby4249.diff [ 12488312 ]
          Hide
          Tiago R. Espinha added a comment -

          Siddharth, is this patch ready for commit? Have you run regressions on it?

          It looks good to me. I see the patch has again white space changes in the first chunk. We'll let it go this time but let's try to get rid of those in the future.

          Show
          Tiago R. Espinha added a comment - Siddharth, is this patch ready for commit? Have you run regressions on it? It looks good to me. I see the patch has again white space changes in the first chunk. We'll let it go this time but let's try to get rid of those in the future.
          Hide
          Siddharth Srivastava added a comment -

          Hi Tiago

          It has passed the regressions tests.

          Show
          Siddharth Srivastava added a comment - Hi Tiago It has passed the regressions tests.
          Hide
          Kathey Marsden added a comment -

          On the permissions issues it might help to add to derby_tests.policy for derbyTesting.jar and derbyTesting.codeclasses, something like
          permission java.io.FilePermission "$

          {java.home}

          $

          {/}

          -", "execute"

          but I am not sure why other tests that use this method don't have the same problem.

          Show
          Kathey Marsden added a comment - On the permissions issues it might help to add to derby_tests.policy for derbyTesting.jar and derbyTesting.codeclasses, something like permission java.io.FilePermission "$ {java.home} $ {/} -", "execute" but I am not sure why other tests that use this method don't have the same problem.
          Hide
          Kathey Marsden added a comment -

          Thank you Siddharth for the patch. I think it is looking very good as a model for the recovery tests.

          I updated the patch with a few changes which I am attaching as derby4249. I enabled security manager by adding the needed lines to the policy file and fixed a preexisting problem with the output when the launched method fails so that it prints the expected output strings and not just the array reference.
          I also added a CleanDatabaseTestSetup decorator so that the schema objects get cleaned up. If nobody objects I will commit after I run some tests.

          Show
          Kathey Marsden added a comment - Thank you Siddharth for the patch. I think it is looking very good as a model for the recovery tests. I updated the patch with a few changes which I am attaching as derby4249. I enabled security manager by adding the needed lines to the policy file and fixed a preexisting problem with the output when the launched method fails so that it prints the expected output strings and not just the array reference. I also added a CleanDatabaseTestSetup decorator so that the schema objects get cleaned up. If nobody objects I will commit after I run some tests.
          Kathey Marsden made changes -
          Attachment derby4249_secmgr_diff.txt [ 12490683 ]
          Kathey Marsden made changes -
          Link This issue is blocked by DERBY-4647 [ DERBY-4647 ]
          Hide
          Kathey Marsden added a comment -

          This test can't run on weme until DERBY-4647 is fixed.

          Show
          Kathey Marsden added a comment - This test can't run on weme until DERBY-4647 is fixed.
          Hide
          Kathey Marsden added a comment -

          The IBM runs failed for the new test last night, I believe because they are still using Junit 3.8.1.
          The test requires JUnit 3.8.2 to allow the -m option to be used. Right now the failure looks like:
          1) testBasicRecovery(org.apache.derbyTesting.functionTests.tests.store.RecoveryTest)junit.framework.AssertionFailedError: expectedExitValue:0 does not match exitValue:1
          expected output strings:
          [0]OK (1 test)
          actual output: expected:<0> but was:<1>
          at org.apache.derbyTesting.junit.BaseTestCase.assertExecJavaCmdAsExpected(BaseTestCase.java:512)
          at org.apache.derbyTesting.junit.BaseTestCase.assertLaunchedJUnitTestMethod(BaseTestCase.java:821)
          at org.apache.derbyTesting.functionTests.tests.store.RecoveryTest.testBasicRecovery(RecoveryTest.java:92)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
          at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:112)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
          at junit.extensions.TestSetup.run(TestSetup.java:23)
          at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:51)

          I am going to post a new patch to improve the error output, but thought I should mention this in case anyone else is still at 3.8.1 and seeing this problem.

          Show
          Kathey Marsden added a comment - The IBM runs failed for the new test last night, I believe because they are still using Junit 3.8.1. The test requires JUnit 3.8.2 to allow the -m option to be used. Right now the failure looks like: 1) testBasicRecovery(org.apache.derbyTesting.functionTests.tests.store.RecoveryTest)junit.framework.AssertionFailedError: expectedExitValue:0 does not match exitValue:1 expected output strings: [0] OK (1 test) actual output: expected:<0> but was:<1> at org.apache.derbyTesting.junit.BaseTestCase.assertExecJavaCmdAsExpected(BaseTestCase.java:512) at org.apache.derbyTesting.junit.BaseTestCase.assertLaunchedJUnitTestMethod(BaseTestCase.java:821) at org.apache.derbyTesting.functionTests.tests.store.RecoveryTest.testBasicRecovery(RecoveryTest.java:92) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:112) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:51) I am going to post a new patch to improve the error output, but thought I should mention this in case anyone else is still at 3.8.1 and seeing this problem.
          Hide
          Kathey Marsden added a comment -

          Here is a patch to include the error output in the error if a launched process fails. With the patch the output when using junit 3.8.1 is:

          1) testBasicRecovery(org.apache.derbyTesting.functionTests.tests.store.RecoveryTest)junit.framework.AssertionFailedError: expectedExi
          match exitValue:1
          expected output strings:
          [0]OK (1 test)
          actual output:<STDOUT> <END STDOUT>
          <STDERR>Class not found "org.apache.derbyTesting.functionTests.tests.store.RecoveryTest.launchRecoveryInsert"
          <END STDERR>
          expected:<0> but was:<1>
          at org.apache.derbyTesting.junit.BaseTestCase.assertExecJavaCmdAsExpected(BaseTestCase.java:512)
          at org.apache.derbyTesting.junit.BaseTestCase.assertLaunchedJUnitTestMethod(BaseTestCase.java:836)
          at org.apache.derbyTesting.functionTests.tests.store.RecoveryTest.testBasicRecovery(RecoveryTest.java:92)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
          at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:112)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
          at junit.extensions.TestSetup.run(TestSetup.java:23)
          at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)

          FAILURES!!!
          Tests run: 1, Failures: 1, Errors: 0

          Show
          Kathey Marsden added a comment - Here is a patch to include the error output in the error if a launched process fails. With the patch the output when using junit 3.8.1 is: 1) testBasicRecovery(org.apache.derbyTesting.functionTests.tests.store.RecoveryTest)junit.framework.AssertionFailedError: expectedExi match exitValue:1 expected output strings: [0] OK (1 test) actual output:<STDOUT> <END STDOUT> <STDERR>Class not found "org.apache.derbyTesting.functionTests.tests.store.RecoveryTest.launchRecoveryInsert" <END STDERR> expected:<0> but was:<1> at org.apache.derbyTesting.junit.BaseTestCase.assertExecJavaCmdAsExpected(BaseTestCase.java:512) at org.apache.derbyTesting.junit.BaseTestCase.assertLaunchedJUnitTestMethod(BaseTestCase.java:836) at org.apache.derbyTesting.functionTests.tests.store.RecoveryTest.testBasicRecovery(RecoveryTest.java:92) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:112) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) FAILURES!!! Tests run: 1, Failures: 1, Errors: 0
          Kathey Marsden made changes -
          Attachment derby4249_showlaunchederr_diff.txt [ 12490820 ]
          Hide
          Kathey Marsden added a comment -

          This test now runs on weme 6.2 with the resolution DERBY-4647. Resolving the issue. Thank you Siddharth for the new test. It is great to have a framework for converting the recovery tests.

          Show
          Kathey Marsden added a comment - This test now runs on weme 6.2 with the resolution DERBY-4647 . Resolving the issue. Thank you Siddharth for the new test. It is great to have a framework for converting the recovery tests.
          Kathey Marsden made changes -
          Status In Progress [ 3 ] Resolved [ 5 ]
          Fix Version/s 10.9.0.0 [ 12316344 ]
          Resolution Fixed [ 1 ]
          Hide
          Knut Anders Hatlen added a comment -

          [bulk update] Close all resolved issues that haven't been updated for more than one year.

          Show
          Knut Anders Hatlen added a comment - [bulk update] Close all resolved issues that haven't been updated for more than one year.
          Knut Anders Hatlen made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Gavin made changes -
          Workflow jira [ 12464594 ] Default workflow, editable Closed status [ 12802748 ]
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          In Progress In Progress Open Open
          15d 6h 1 Siddharth Srivastava 25/Jun/11 16:20
          Open Open In Progress In Progress
          742d 16h 57m 2 Siddharth Srivastava 25/Jun/11 16:20
          In Progress In Progress Resolved Resolved
          60d 2h 18m 1 Kathey Marsden 24/Aug/11 18:38
          Resolved Resolved Closed Closed
          662d 15h 40m 1 Knut Anders Hatlen 17/Jun/13 10:19

            People

            • Assignee:
              Siddharth Srivastava
              Reporter:
              Kathey Marsden
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development