Derby
  1. Derby
  2. DERBY-4836

many failures with IBM 1.5 and 1.6 on windows after test InternationalConnectTest

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.7.1.1
    • Fix Version/s: 10.7.1.1
    • Component/s: Test
    • Labels:
      None
    • Environment:
      Windows XP with ibm 1.5. SR11 FP1, and ibm 1.6 SR8.
    • Bug behavior facts:
      Regression Test Failure

      Description

      After changes for DERBY-4757, revision 1004460, multiple tests are failing with ibm 1.5 and 1.6 jvms on windows XP.
      See: http://people.apache.org/~myrnavl/derby_test_results/main/windows/testSummary-1004498.html

      The first error is this (linebreaks inserted at [\n] for readability of this JIRA):
      1) testBoundaries(org.apache.derbyTesting.functionTests.tests.jdbcapi.InternationalConnectTest)java.sql.SQLException:[\n]
      DERBY SQL error: SQLCODE: -1, SQLSTATE: XJ001, SQLERRMC: java.security.AccessControlExceptionAccess denied[\n]
      (java.io.FilePermission C:\derbyt\tst\system\AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[\n]
      AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[\n]
      AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\tmp delete)[\n]
      XJ001.U
      at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:96)
      at org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:358)
      at org.apache.derby.jdbc.ClientDriver.connect(ClientDriver.java:149)
      at java.sql.DriverManager.getConnection(DriverManager.java:322)
      at java.sql.DriverManager.getConnection(DriverManager.java:273)
      at org.apache.derbyTesting.functionTests.tests.jdbcapi.InternationalConnectTest.testBoundaries(InternationalConnectTest.java:92)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:109)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
      at junit.extensions.TestSetup.run(TestSetup.java:16)
      at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
      at junit.extensions.TestSetup.run(TestSetup.java:16)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
      at junit.extensions.TestSetup.run(TestSetup.java:16)
      at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
      Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: -1, SQLSTATE: XJ001, SQLERRMC: [\n]
      java.security.AccessControlExceptionAccess denied (java.io.FilePermission C:\derbyt\tst\system\AAAAAAAAAAAAAAAAAAA[\n]
      AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[\n]
      AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA[\n]
      AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\tmp delete)XJ001.U
      at org.apache.derby.client.am.Connection.completeSqlca(Connection.java:2117)
      at org.apache.derby.client.net.NetConnectionReply.parseRdbAccessFailed(NetConnectionReply.java:541)
      at org.apache.derby.client.net.NetConnectionReply.parseAccessRdbError(NetConnectionReply.java:434)
      at org.apache.derby.client.net.NetConnectionReply.parseACCRDBreply(NetConnectionReply.java:297)
      at org.apache.derby.client.net.NetConnectionReply.readAccessDatabase(NetConnectionReply.java:121)
      at org.apache.derby.client.net.NetConnection.readSecurityCheckAndAccessRdb(NetConnection.java:846)
      at org.apache.derby.client.net.NetConnection.flowSecurityCheckAndAccessRdb(NetConnection.java:769)
      at org.apache.derby.client.net.NetConnection.flowUSRIDONLconnect(NetConnection.java:601)
      at org.apache.derby.client.net.NetConnection.flowConnect(NetConnection.java:408)
      at org.apache.derby.client.net.NetConnection.<init>(NetConnection.java:218)
      at org.apache.derby.client.net.NetConnection40.<init>(NetConnection40.java:77)
      at org.apache.derby.client.net.ClientJDBCObjectFactoryImpl40.newNetConnection(ClientJDBCObjectFactoryImpl40.java:269)
      at org.apache.derby.jdbc.ClientDriver.connect(ClientDriver.java:83)
      ... 41 more
      ==========================
      after which other tests fail with database shutdown errors and the like. For instance:
      ==========================
      2) shutdownDerby(org.apache.derbyTesting.functionTests.tests.store.BootAllTest)java.lang.NullPointerException
      at org.apache.derby.impl.services.monitor.TopService.getService(Unknown Source)
      at org.apache.derby.impl.services.monitor.BaseMonitor.shutdown(Unknown Source)
      at org.apache.derby.jdbc.InternalDriver.connect(Unknown Source)
      at org.apache.derby.jdbc.AutoloadedDriver.connect(Unknown Source)
      at java.sql.DriverManager.getConnection(DriverManager.java:572)
      at java.sql.DriverManager.getConnection(DriverManager.java:165)
      at org.apache.derbyTesting.junit.DriverManagerConnector.getConnectionByAttributes(DriverManagerConnector.java:134)
      at org.apache.derbyTesting.junit.DriverManagerConnector.shutEngine(DriverManagerConnector.java:117)
      at org.apache.derbyTesting.junit.TestConfiguration.shutdownEngine(TestConfiguration.java:1522)
      at org.apache.derbyTesting.functionTests.tests.store.BootAllTest.shutdownDerby(BootAllTest.java:116)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:109)
      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)
      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 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)
      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 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)
      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)

      ===============

      This does not occur with the sun jdk on this hardware (build 1.6.0_21-b07).
      It also does not occur with the same jvm levels on unix.

      Interestingly, when I try running the test by itself with ibm 1.6 on windows, it also fails:
      ===============
      1) testBoundaries(org.apache.derbyTesting.functionTests.tests.jdbcapi.InternationalConnectTest)java.sql.SQLException: No suitable driver
      at java.sql.DriverManager.getConnection(DriverManager.java:330)
      at java.sql.DriverManager.getConnection(DriverManager.java:273)
      at org.apache.derbyTesting.functionTests.tests.jdbcapi.InternationalConnectTest.testBoundaries(InternationalConnectTest.java:92)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:109)
      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)
      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 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)

      This is the second time testBoundaries fixture gets run.

      This does happen on linux with the same jvm level (ibm16 sr8), but does this occur on Windows XP with sun/oracle jdk 1.6.

      1. DERBY-4836_revive.diff
        1 kB
        Myrna van Lunteren
      2. DERBY-4836_tmpskiptest.diff
        1 kB
        Myrna van Lunteren
      3. DERBY-4836.diff
        6 kB
        Tiago R. Espinha
      4. DERBY-4836.diff
        2 kB
        Tiago R. Espinha
      5. DERBY-4836.diff
        1 kB
        Tiago R. Espinha
      6. jvm1.4-derby.log
        31 kB
        Knut Anders Hatlen
      7. shutdown.diff
        2 kB
        Knut Anders Hatlen

        Issue Links

          Activity

          Hide
          Myrna van Lunteren added a comment -

          committed the revive of this test for IBM 1.5 and 1.6 jvms (requires 1.6 SR9 and 1.5 SR13) with revision 1213473 on trunk (10.9 alpha).
          closing again

          Show
          Myrna van Lunteren added a comment - committed the revive of this test for IBM 1.5 and 1.6 jvms (requires 1.6 SR9 and 1.5 SR13) with revision 1213473 on trunk (10.9 alpha). closing again
          Hide
          Myrna van Lunteren added a comment -

          This test now passes with the newly released IBM 1.5 SR13, so it can be revived for that jvm.
          It's still not working for 1.4.2 jvms.

          Also adding the getConnection() call that we decided was ok to be added.

          I intend to commit this shortly.

          Show
          Myrna van Lunteren added a comment - This test now passes with the newly released IBM 1.5 SR13, so it can be revived for that jvm. It's still not working for 1.4.2 jvms. Also adding the getConnection() call that we decided was ok to be added. I intend to commit this shortly.
          Hide
          Tiago R. Espinha added a comment -

          Thank you very much Myrna and Knut for resolving this. I've just moved to a different country and I'm still settling in, that's why I haven't had much time to be on top of this issue.

          Thanks again!

          Show
          Tiago R. Espinha added a comment - Thank you very much Myrna and Knut for resolving this. I've just moved to a different country and I'm still settling in, that's why I haven't had much time to be on top of this issue. Thanks again!
          Hide
          Myrna van Lunteren added a comment -

          I think this issue can now be closed - what's remaining is for me to wait until the jvm issue issue fixed, and then I can reinstate the test for the ibm jvms. We don't need to keep this open for that.

          Show
          Myrna van Lunteren added a comment - I think this issue can now be closed - what's remaining is for me to wait until the jvm issue issue fixed, and then I can reinstate the test for the ibm jvms. We don't need to keep this open for that.
          Hide
          Myrna van Lunteren added a comment -

          spin off issue for the NPE found during one of the iterations.

          Show
          Myrna van Lunteren added a comment - spin off issue for the NPE found during one of the iterations.
          Hide
          Myrna van Lunteren added a comment -

          With the latest incarnation of the test, I again commented out the skipping with ibm jvms, and added a getConnection call to the top of testBoundaries.
          With that, I see no problem when I run with classes, either with sun or ibm jvm (only tried 1.6) - not even the ibm jvm issue with the AccessControlException - that I decided was an issue with the long name and the File(String, String) constructor on windows.

          However, running the test by itself with ibm 1.6 and jars (sane), I see some unusual errors:
          There was 1 error:
          1) testBoundaries(org.apache.derbyTesting.functionTests.tests.jdbcapi.InternationalConnectTest)java.sql.SQLException: DERBY SQL error: SQLCODE: -1, SQLSTATE: XJ001, SQLERRMC: java.lang.NullPointerExceptionXJ001.U
          ...
          Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: -1, SQLSTATE: XJ001, SQLERRMC: java.lang.NullPointerExceptionXJ001.U
          ...

          Looking at derby.log, I see the following interesting sequence:
          ------------------
          Wed Oct 27 14:23:37 PDT 2010 Thread[main,5,main] Cleanup action starting
          java.sql.SQLException: Database 'wombat' not found.
          ...
          [booting and shuttding down of a couple of instances with classloader...]
          ....
          Wed Oct 27 14:23:46 PDT 2010 Thread[main,5,main] Cleanup action starting
          java.sql.SQLException: Database 'abcdefghijklmnopqå' not found.
          ...
          at org.apache.derbyTesting.functionTests.tests.jdbcapi.InternationalConnectTest.testFailureOnNonExistentDatabase(InternationalConnectTest.java:255)
          ...
          Wed Oct 27 14:23:47 PDT 2010 Thread[DRDAConnThread_10,5,derby.daemons] Cleanup action starting
          java.lang.NullPointerException
          at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.stop(BaseDataFileFactory.java:471)
          at org.apache.derby.impl.services.monitor.TopService.stop(TopService.java:442)
          ...
          Wed Oct 27 14:23:47 PDT 2010 Thread[DRDAConnThread_10,5,derby.daemons] (DATABASE = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
          AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
          AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA),
          (DRDAID =

          {3}

          ), Java exception: ': java.lang.NullPointerException'.
          ....
          Wed Oct 27 14:23:51 PDT 2010 Thread[DRDAConnThread_14,5,derby.daemons] (DATABASE = ?), (DRDAID =

          {14}

          ), Database '?' shutdown.
          ...
          Wed Oct 27 14:23:51 PDT 2010 Thread[DRDAConnThread_11,5,derby.daemons] (DATABASE = ?), (DRDAID = .-4255055934720357393

          {11}

          ), ASSERT FAILED pbsd is not expected to be null
          Wed Oct 27 14:23:51 PDT 2010 : ASSERT FAILED pbsd is not expected to be null
          org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED pbsd is not expected to be null
          at org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:120)
          at org.apache.derby.impl.drda.DRDAConnThread.writePBSD(DRDAConnThread.java:2726)
          at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:1044)
          at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:294)
          ---------------
          Stack traces for all live threads:
          ...
          ------
          This doesn't happen with sun/oracle jdk 1.6
          I'll confirm my environment is not messed up, and then log a new bug for that one, and attach the full derby.log. It seems the attempt to shutdown the non-existant database succeeded only partially, leaving everything in a weird state.

          Show
          Myrna van Lunteren added a comment - With the latest incarnation of the test, I again commented out the skipping with ibm jvms, and added a getConnection call to the top of testBoundaries. With that, I see no problem when I run with classes, either with sun or ibm jvm (only tried 1.6) - not even the ibm jvm issue with the AccessControlException - that I decided was an issue with the long name and the File(String, String) constructor on windows. However, running the test by itself with ibm 1.6 and jars (sane), I see some unusual errors: There was 1 error: 1) testBoundaries(org.apache.derbyTesting.functionTests.tests.jdbcapi.InternationalConnectTest)java.sql.SQLException: DERBY SQL error: SQLCODE: -1, SQLSTATE: XJ001, SQLERRMC: java.lang.NullPointerExceptionXJ001.U ... Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: -1, SQLSTATE: XJ001, SQLERRMC: java.lang.NullPointerExceptionXJ001.U ... Looking at derby.log, I see the following interesting sequence: ------------------ Wed Oct 27 14:23:37 PDT 2010 Thread [main,5,main] Cleanup action starting java.sql.SQLException: Database 'wombat' not found. ... [booting and shuttding down of a couple of instances with classloader...] .... Wed Oct 27 14:23:46 PDT 2010 Thread [main,5,main] Cleanup action starting java.sql.SQLException: Database 'abcdefghijklmnopqå' not found. ... at org.apache.derbyTesting.functionTests.tests.jdbcapi.InternationalConnectTest.testFailureOnNonExistentDatabase(InternationalConnectTest.java:255) ... Wed Oct 27 14:23:47 PDT 2010 Thread [DRDAConnThread_10,5,derby.daemons] Cleanup action starting java.lang.NullPointerException at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.stop(BaseDataFileFactory.java:471) at org.apache.derby.impl.services.monitor.TopService.stop(TopService.java:442) ... Wed Oct 27 14:23:47 PDT 2010 Thread [DRDAConnThread_10,5,derby.daemons] (DATABASE = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA), (DRDAID = {3} ), Java exception: ': java.lang.NullPointerException'. .... Wed Oct 27 14:23:51 PDT 2010 Thread [DRDAConnThread_14,5,derby.daemons] (DATABASE = ?), (DRDAID = {14} ), Database '?' shutdown. ... Wed Oct 27 14:23:51 PDT 2010 Thread [DRDAConnThread_11,5,derby.daemons] (DATABASE = ?), (DRDAID = .-4255055934720357393 {11} ), ASSERT FAILED pbsd is not expected to be null Wed Oct 27 14:23:51 PDT 2010 : ASSERT FAILED pbsd is not expected to be null org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED pbsd is not expected to be null at org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:120) at org.apache.derby.impl.drda.DRDAConnThread.writePBSD(DRDAConnThread.java:2726) at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:1044) at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:294) --------------- Stack traces for all live threads: ... ------ This doesn't happen with sun/oracle jdk 1.6 I'll confirm my environment is not messed up, and then log a new bug for that one, and attach the full derby.log. It seems the attempt to shutdown the non-existant database succeeded only partially, leaving everything in a weird state.
          Hide
          Knut Anders Hatlen added a comment -

          I think it would be fine to add a call to getConnection() at the top of testBoundaries(). It was probably added to testDriverManagerConnect() because it used to be the first test case running, but it's not now that testBoundaries() was added at the top. Perhaps it's better to add it to a setUp() method, so that we won't get the same problem if a new test case is added?

          I had expected that a connection would have been opened (and then the driver would be loaded) by the CleanDatabaseTestSetup that decorates the test suite, though. But it looks like TestConfiguration.defaultSuite() adds the clean database decorator outside the client/server decorator, and I think that means the setUp/tearDown code of the decorator will use the embedded driver. Hence, it won't cause the client driver to be loaded.

          Show
          Knut Anders Hatlen added a comment - I think it would be fine to add a call to getConnection() at the top of testBoundaries(). It was probably added to testDriverManagerConnect() because it used to be the first test case running, but it's not now that testBoundaries() was added at the top. Perhaps it's better to add it to a setUp() method, so that we won't get the same problem if a new test case is added? I had expected that a connection would have been opened (and then the driver would be loaded) by the CleanDatabaseTestSetup that decorates the test suite, though. But it looks like TestConfiguration.defaultSuite() adds the clean database decorator outside the client/server decorator, and I think that means the setUp/tearDown code of the decorator will use the embedded driver. Hence, it won't cause the client driver to be loaded.
          Hide
          Knut Anders Hatlen added a comment -

          I also see the no suitable driver error when running the test standalone from classes, but the error goes away when I run it from jars (probably because of driver auto-loading).

          Show
          Knut Anders Hatlen added a comment - I also see the no suitable driver error when running the test standalone from classes, but the error goes away when I run it from jars (probably because of driver auto-loading).
          Hide
          Knut Anders Hatlen added a comment -

          I committed the patch with revision 1028035. It'll hopefully work now, but the fix went in just too late to be part of the next test cycle, so we won't see the results in the Sun test reports until Friday.

          Show
          Knut Anders Hatlen added a comment - I committed the patch with revision 1028035. It'll hopefully work now, but the fix went in just too late to be part of the next test cycle, so we won't see the results in the Sun test reports until Friday.
          Hide
          Myrna van Lunteren added a comment -

          I forgot to mention what I found regarding the 'No suitable driver' error I got when running the test by itself:

          • it occurs with both sun and ibm jvms
          • it goes away if I add the following before the first DriverManager.getConnection(url);
            -----------------
            try { Class.forName("org.apache.derby.jdbc.ClientDriver").newInstance(); }

            catch (IllegalAccessException e)

            { // TODO Auto-generated catch block e.printStackTrace(); } catch (InstantiationException e) { // TODO Auto-generated catch block e.printStackTrace(); }

            catch (ClassNotFoundException e)

            { // TODO Auto-generated catch block e.printStackTrace(); }

            //(my IDE put those TODO's in, should be cleaned up)
            ---------------

          • the difference between how this fixture starts and the fixture testDriverManagerConnect is these two lines:
            -------------------
            //get a connection to load the driver
            getConnection();
            -------------------
            I don't know if the driver was expected to be autoloaded and that's not working, but as this has been in the test since it got first created, I assume this is acceptable.

          So, there are two ways to get around that error situation.

          I'll take a closer look at the assertion failure on windows, for I have the windows system to look at.

          Show
          Myrna van Lunteren added a comment - I forgot to mention what I found regarding the 'No suitable driver' error I got when running the test by itself: it occurs with both sun and ibm jvms it goes away if I add the following before the first DriverManager.getConnection(url); ----------------- try { Class.forName("org.apache.derby.jdbc.ClientDriver").newInstance(); } catch (IllegalAccessException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (InstantiationException e) { // TODO Auto-generated catch block e.printStackTrace(); } catch (ClassNotFoundException e) { // TODO Auto-generated catch block e.printStackTrace(); } //(my IDE put those TODO's in, should be cleaned up) --------------- the difference between how this fixture starts and the fixture testDriverManagerConnect is these two lines: ------------------- //get a connection to load the driver getConnection(); ------------------- I don't know if the driver was expected to be autoloaded and that's not working, but as this has been in the test since it got first created, I assume this is acceptable. So, there are two ways to get around that error situation. I'll take a closer look at the assertion failure on windows, for I have the windows system to look at.
          Hide
          Knut Anders Hatlen added a comment -

          I believe the attached patch will fix the issue. I haven't tested it on Windows, though. The patch makes the following changes to the test:

          1) Make tearDown() fail if it cannot shut down the database, so that we're told about problems.

          2) Don't add database to list of databasesForCleanup in testFailureOnNonExistentDatabase(), since that test case doesn't create a database.

          3) Make testBoundaries() use a database name that's two characters shorter, so that it doesn't exceed the limit when shutdown=true is added to it.

          Show
          Knut Anders Hatlen added a comment - I believe the attached patch will fix the issue. I haven't tested it on Windows, though. The patch makes the following changes to the test: 1) Make tearDown() fail if it cannot shut down the database, so that we're told about problems. 2) Don't add database to list of databasesForCleanup in testFailureOnNonExistentDatabase(), since that test case doesn't create a database. 3) Make testBoundaries() use a database name that's two characters shorter, so that it doesn't exceed the limit when shutdown=true is added to it.
          Hide
          Knut Anders Hatlen added a comment -

          Looks like the database isn't really shut down. Maximum db name length is 255 including connection attributes. testBoundaries() account for ";create=true" (12 characters) but not ";shutdown=true" (14 characters), so the shutdown command fails.

          Show
          Knut Anders Hatlen added a comment - Looks like the database isn't really shut down. Maximum db name length is 255 including connection attributes. testBoundaries() account for ";create=true" (12 characters) but not ";shutdown=true" (14 characters), so the shutdown command fails.
          Hide
          Myrna van Lunteren added a comment -

          Firstly, I filed a bug against the ibm 1.5 and 1.6 jvms re the security.AccessControlException.

          Then, it looks like the test is now fine (i.e. getting skipped) with sun's jdk 1.4.2: http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-1027607.html shows no failures.
          I also verified the tests are running and the files are getting cleaned up with ibm 1.6 jvm on linux. The test also gets skipped for ibm 1.5 and 1.6 on windows.

          However, I ran the test with my temporary suite with the test enabled for ibm1.6 on windows, it doesn't clean up the database correctly on that platform - it chokes on removing AAA*AAA/db.lck.
          Not sure why. I see the same is happening for sun/oracle jvms: http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-1027607.html.

          Show
          Myrna van Lunteren added a comment - Firstly, I filed a bug against the ibm 1.5 and 1.6 jvms re the security.AccessControlException. Then, it looks like the test is now fine (i.e. getting skipped) with sun's jdk 1.4.2: http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-1027607.html shows no failures. I also verified the tests are running and the files are getting cleaned up with ibm 1.6 jvm on linux. The test also gets skipped for ibm 1.5 and 1.6 on windows. However, I ran the test with my temporary suite with the test enabled for ibm1.6 on windows, it doesn't clean up the database correctly on that platform - it chokes on removing AAA*AAA/db.lck. Not sure why. I see the same is happening for sun/oracle jvms: http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-1027607.html .
          Hide
          Tiago R. Espinha added a comment -

          Oh, you're right Knut! I forgot these tests were actually failing in the first place for Sun's JVM. When I saw that, I assumed it had been my changes

          I'll wait for the next report then.

          Show
          Tiago R. Espinha added a comment - Oh, you're right Knut! I forgot these tests were actually failing in the first place for Sun's JVM. When I saw that, I assumed it had been my changes I'll wait for the next report then.
          Hide
          Knut Anders Hatlen added a comment -

          The latest nightly test report was for an earlier revision (1027173) that didn't include the fix. Hopefully, it'll look better when the next report is sent out later today.

          Show
          Knut Anders Hatlen added a comment - The latest nightly test report was for an earlier revision (1027173) that didn't include the fix. Hopefully, it'll look better when the next report is sent out later today.
          Hide
          Tiago R. Espinha added a comment -

          Regressions failed on the daily run. Somehow the test is not being skipped on Sun's 1.4.2 under Windows.

          Show
          Tiago R. Espinha added a comment - Regressions failed on the daily run. Somehow the test is not being skipped on Sun's 1.4.2 under Windows.
          Hide
          Tiago R. Espinha added a comment -

          Resolved in revision 1027261.

          Show
          Tiago R. Espinha added a comment - Resolved in revision 1027261.
          Hide
          Tiago R. Espinha added a comment -

          Thank you Knut for reviewing. I've added a few more simple changes to cleanup all the databases created by the test. Since these are small changes to tests only, I'm gonna go ahead and commit this new patch.

          Show
          Tiago R. Espinha added a comment - Thank you Knut for reviewing. I've added a few more simple changes to cleanup all the databases created by the test. Since these are small changes to tests only, I'm gonna go ahead and commit this new patch.
          Hide
          Knut Anders Hatlen added a comment -

          The patch looks fine to me. Thanks.

          Show
          Knut Anders Hatlen added a comment - The patch looks fine to me. Thanks.
          Hide
          Tiago R. Espinha added a comment -

          Attaching a new patch that should skip IBM JVMs (only for this specific fixture, as opposed to skipping the whole test) and Sun <= 1.4.2_xx.

          I'm still getting some issues with the databases with really long names not being cleaned up and I'm still investigating this. I've noticed that the database with just 1 international character gets cleaned up, but not the ones with long names.

          Show
          Tiago R. Espinha added a comment - Attaching a new patch that should skip IBM JVMs (only for this specific fixture, as opposed to skipping the whole test) and Sun <= 1.4.2_xx. I'm still getting some issues with the databases with really long names not being cleaned up and I'm still investigating this. I've noticed that the database with just 1 international character gets cleaned up, but not the ones with long names.
          Hide
          Myrna van Lunteren added a comment -

          I am definitely not seeing the same problem with the sun 1.4.2. jvm that Knut refers to with the IBM 1.5 and 1.6 jvms.
          I'm working on a repro but other stuff keeps pushing to the front, so it's taking longer than I had hoped.

          At the same time, on Linux, where this test passed with IBM jvms 1.5 and 1.6, the test left behind some databases with really big names, one of them including only c-cedilles.
          And one of my backup tools is choking on this; so I'd like for now, at least until I've looked into that one, to not run this test with ibm jvms at all...

          Show
          Myrna van Lunteren added a comment - I am definitely not seeing the same problem with the sun 1.4.2. jvm that Knut refers to with the IBM 1.5 and 1.6 jvms. I'm working on a repro but other stuff keeps pushing to the front, so it's taking longer than I had hoped. At the same time, on Linux, where this test passed with IBM jvms 1.5 and 1.6, the test left behind some databases with really big names, one of them including only c-cedilles. And one of my backup tools is choking on this; so I'd like for now, at least until I've looked into that one, to not run this test with ibm jvms at all...
          Hide
          Knut Anders Hatlen added a comment -

          The version number in this check looks a bit too specific:

          getSystemProperty("java.version").equals("1.4.2_19")

          The JVMs that fail in Ole's nightly tests will have 1.4.2_13 and 1.4.2_16 in that property. What about startsWith("1.4.2") instead?

          And instead of getSystemProperty("java.vendor").equals("Sun Microsystems Inc."), you could use the helper method isSunJVM(). It doesn't look like there's a corresponding helper method to check if the vendor is IBM, though.

          Show
          Knut Anders Hatlen added a comment - The version number in this check looks a bit too specific: getSystemProperty("java.version").equals("1.4.2_19") The JVMs that fail in Ole's nightly tests will have 1.4.2_13 and 1.4.2_16 in that property. What about startsWith("1.4.2") instead? And instead of getSystemProperty("java.vendor").equals("Sun Microsystems Inc."), you could use the helper method isSunJVM(). It doesn't look like there's a corresponding helper method to check if the vendor is IBM, though.
          Hide
          Tiago R. Espinha added a comment -

          This patch should make the test skip on IBM JVMs and on Sun's 1.4.2.

          I currently don't have a Windows machine to test this on. Does anyone volunteer to run InternationalConnectTest with and without the patch on Windows using Sun 1.4.2?

          It should be fairly straight forward and it should be working, but just to be safe.

          With this patch I'm skipping IBM JVMs altogether, meaning that we'll skip even newer versions. Do you think this is ok or should I only skip up to 1.6 (the current version)? I think it would be interesting to hardcode the version if IBM was actually working on this but for all we know, further versions will still have this issue.

          Show
          Tiago R. Espinha added a comment - This patch should make the test skip on IBM JVMs and on Sun's 1.4.2. I currently don't have a Windows machine to test this on. Does anyone volunteer to run InternationalConnectTest with and without the patch on Windows using Sun 1.4.2? It should be fairly straight forward and it should be working, but just to be safe. With this patch I'm skipping IBM JVMs altogether, meaning that we'll skip even newer versions. Do you think this is ok or should I only skip up to 1.6 (the current version)? I think it would be interesting to hardcode the version if IBM was actually working on this but for all we know, further versions will still have this issue.
          Hide
          Knut Anders Hatlen added a comment -

          Sounds fine to me. Since it only seems to affect windows, perhaps we should also check the os.name system property and only exclude those JVMs on Windows?

          Show
          Knut Anders Hatlen added a comment - Sounds fine to me. Since it only seems to affect windows, perhaps we should also check the os.name system property and only exclude those JVMs on Windows?
          Hide
          Tiago R. Espinha added a comment -

          I would think that despite it throwing a different exception on the IBM JVMs, the underlying issue is probably the same. Shall we make a patch to skip Sun's 1.4.2 and the IBM JVMs altogether?

          Show
          Tiago R. Espinha added a comment - I would think that despite it throwing a different exception on the IBM JVMs, the underlying issue is probably the same. Shall we make a patch to skip Sun's 1.4.2 and the IBM JVMs altogether?
          Hide
          Knut Anders Hatlen added a comment -

          Attaching derby.log from one of the runs on Sun's 1.4.2.

          The underlying exception is the following, which supports Tiago's hypothesis:

          ERROR XSLAQ: cannot create log file at directory C:\cludev\jagtmp\autoderbyN_derbyall\suitesAll_1\log\system\AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\log.

          at org.apache.derby.iapi.error.StandardException.newException(Unknown Source)

          at org.apache.derby.impl.store.raw.log.LogToFile.getLogDirectory(Unknown Source)

          at org.apache.derby.impl.store.raw.log.LogToFile.getControlFileName(Unknown Source)

          at org.apache.derby.impl.store.raw.log.LogToFile.boot(Unknown Source)

          Show
          Knut Anders Hatlen added a comment - Attaching derby.log from one of the runs on Sun's 1.4.2. The underlying exception is the following, which supports Tiago's hypothesis: ERROR XSLAQ: cannot create log file at directory C:\cludev\jagtmp\autoderbyN_derbyall\suitesAll_1\log\system\AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\log. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.store.raw.log.LogToFile.getLogDirectory(Unknown Source) at org.apache.derby.impl.store.raw.log.LogToFile.getControlFileName(Unknown Source) at org.apache.derby.impl.store.raw.log.LogToFile.boot(Unknown Source)
          Hide
          Knut Anders Hatlen added a comment -

          It could be this bug: http://bugs.sun.com/view_bug.do?bug_id=4403166
          Which was fixed in Java SE 6.0 and backported to 5.0 in one of the early update releases.

          For the Sun VMs, I'd be happy with a solution that simply skipped testBoundaries() on 1.4.2. Testing this on newer JVMs should be enough to detect regressions.

          I'm not sure if the issue seen on the IBM VMs is the same though. The stack trace Myrna posted seems to indicate it's a permission problem, but neither the stack trace nor derby.log contains any traces of permission problems in the Sun tests.

          Show
          Knut Anders Hatlen added a comment - It could be this bug: http://bugs.sun.com/view_bug.do?bug_id=4403166 Which was fixed in Java SE 6.0 and backported to 5.0 in one of the early update releases. For the Sun VMs, I'd be happy with a solution that simply skipped testBoundaries() on 1.4.2. Testing this on newer JVMs should be enough to detect regressions. I'm not sure if the issue seen on the IBM VMs is the same though. The stack trace Myrna posted seems to indicate it's a permission problem, but neither the stack trace nor derby.log contains any traces of permission problems in the Sun tests.
          Hide
          Bryan Pendleton added a comment -

          Indeed, from the original description, the folder is ' C:\derbyt\tst\system\', which is more than 5 characters long. Tiago, I think your explanation rings true.

          Show
          Bryan Pendleton added a comment - Indeed, from the original description, the folder is ' C:\derbyt\tst\system\', which is more than 5 characters long. Tiago, I think your explanation rings true.
          Hide
          Myrna van Lunteren added a comment -

          One more piece of information from yesterday's experiments: with classes (not jars) and set to sane=true, my subset of the tests doesn't fail, using the same ibm 1.6 jvm. Running the test by itself does fail.

          Show
          Myrna van Lunteren added a comment - One more piece of information from yesterday's experiments: with classes (not jars) and set to sane=true, my subset of the tests doesn't fail, using the same ibm 1.6 jvm. Running the test by itself does fail.
          Hide
          Myrna van Lunteren added a comment -

          breaking up the text to display the jira more conveniently in my browser.

          Show
          Myrna van Lunteren added a comment - breaking up the text to display the jira more conveniently in my browser.
          Hide
          Tiago R. Espinha added a comment -

          I don't have much knowledge of how the JVMs implement IO access but if they resort to the Win32 API, then I might have found the source of the problem.

          This link [1] explains that "the maximum length for a path is MAX_PATH, which is defined as 260 characters". But it also says that some functions "also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters."

          Could it be that Sun's 1.4 and IBM's JVMs are using these stricter API functions and thus the limit for the whole path is 260 characters? If this were to be true, then considering that the database is inside other folders, we would easily go over this limit as the database name itself uses 255 characters.

          [1] - http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#maxpath

          Show
          Tiago R. Espinha added a comment - I don't have much knowledge of how the JVMs implement IO access but if they resort to the Win32 API, then I might have found the source of the problem. This link [1] explains that "the maximum length for a path is MAX_PATH, which is defined as 260 characters". But it also says that some functions "also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters." Could it be that Sun's 1.4 and IBM's JVMs are using these stricter API functions and thus the limit for the whole path is 260 characters? If this were to be true, then considering that the database is inside other folders, we would easily go over this limit as the database name itself uses 255 characters. [1] - http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx#maxpath
          Hide
          Knut Anders Hatlen added a comment -

          This is also seen with Sun's 1.4.2 on Windows:

          http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-1005095.html

          1.5 and 1.6 were clean.

          Show
          Knut Anders Hatlen added a comment - This is also seen with Sun's 1.4.2 on Windows: http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.4/testing/Limited/testSummary-1005095.html 1.5 and 1.6 were clean.
          Hide
          Tiago R. Espinha added a comment -

          Myrna, if you have the time could you please try creating a test application that attempts to create a database with 255 characters ('A' as the repeating character) under the IBM JVM? I'm away from my own computer until Monday so I can't test anything myself until then but it would be interesting to see if with a previous release (say, 10.6.2) and the IBM JVM we are able to create databases with names whose length is right on the maximum limit.

          If this is a quirk of the IBM JVM then maybe skipping the test for it is the way to go in the long run.

          Show
          Tiago R. Espinha added a comment - Myrna, if you have the time could you please try creating a test application that attempts to create a database with 255 characters ('A' as the repeating character) under the IBM JVM? I'm away from my own computer until Monday so I can't test anything myself until then but it would be interesting to see if with a previous release (say, 10.6.2) and the IBM JVM we are able to create databases with names whose length is right on the maximum limit. If this is a quirk of the IBM JVM then maybe skipping the test for it is the way to go in the long run.
          Hide
          Myrna van Lunteren added a comment -

          committed the skipping patch with revision 1005285.

          Show
          Myrna van Lunteren added a comment - committed the skipping patch with revision 1005285.
          Hide
          Myrna van Lunteren added a comment -

          Attaching a patch that will cause the test run to skip over this test with ibm jvms while I do further investigations. I'll commit this shortly. I've not run suites.All with this, just a temporary suite, and the test itself.

          Show
          Myrna van Lunteren added a comment - Attaching a patch that will cause the test run to skip over this test with ibm jvms while I do further investigations. I'll commit this shortly. I've not run suites.All with this, just a temporary suite, and the test itself.
          Hide
          Myrna van Lunteren added a comment -

          I'm not quite sure still what's happening here, but I suggest preventing the test from running with ibm jvms for the time being.

          Show
          Myrna van Lunteren added a comment - I'm not quite sure still what's happening here, but I suggest preventing the test from running with ibm jvms for the time being.

            People

            • Assignee:
              Tiago R. Espinha
              Reporter:
              Myrna van Lunteren
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development