Derby
  1. Derby
  2. DERBY-3709

Exception printed by replication test: Could not perform operation because the database is not in replication master mode.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.4.2.0, 10.5.1.1
    • Fix Version/s: 10.4.2.0
    • Component/s: Replication
    • Labels:
      None
    • Environment:
      Java Version: 1.6.0_04
      Java Vendor: Sun Microsystems Inc.
      OS name: SunOS
      OS architecture: x86
      OS version: 5.10
    • Bug behavior facts:
      Regression Test Failure

      Description

      I saw the following exception printed when I ran suites.All on trunk (revision 663064). None of the tests failed.

      java.sql.SQLException: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE07, SQLERRMC: Could not perform operation because the database is not in replication master mode.
      at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:96)
      at org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:362)
      at org.apache.derby.jdbc.ClientDriver.connect(ClientDriver.java:149)
      at java.sql.DriverManager.getConnection(DriverManager.java:582)
      at java.sql.DriverManager.getConnection(DriverManager.java:207)
      at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.failOver_direct(ReplicationRun.java:1286)
      at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun.failOver(ReplicationRun.java:1220)
      at org.apache.derbyTesting.functionTests.tests.replicationTests.ReplicationRun_Local.testReplication_Local(ReplicationRun_Local.java:148)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:597)
      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:104)
      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.extensions.TestDecorator.basicRun(TestDecorator.java:24)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
      at junit.framework.TestResult.runProtected(TestResult.java:124)
      at junit.extensions.TestSetup.run(TestSetup.java:25)
      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)
      Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: -1, SQLSTATE: XRE07, SQLERRMC: Could not perform operation because the database is not in replication master mode.
      at org.apache.derby.client.am.Connection.completeSqlca(Connection.java:2068)
      at org.apache.derby.client.net.NetConnectionReply.parseRdbAccessFailed(NetConnectionReply.java:537)
      at org.apache.derby.client.net.NetConnectionReply.parseAccessRdbError(NetConnectionReply.java:430)
      at org.apache.derby.client.net.NetConnectionReply.parseACCRDBreply(NetConnectionReply.java:294)
      at org.apache.derby.client.net.NetConnectionReply.readAccessDatabase(NetConnectionReply.java:121)
      at org.apache.derby.client.net.NetConnection.readSecurityCheckAndAccessRdb(NetConnection.java:831)
      at org.apache.derby.client.net.NetConnection.flowSecurityCheckAndAccessRdb(NetConnection.java:755)
      at org.apache.derby.client.net.NetConnection.flowUSRIDONLconnect(NetConnection.java:588)
      at org.apache.derby.client.net.NetConnection.flowConnect(NetConnection.java:395)
      at org.apache.derby.client.net.NetConnection.<init>(NetConnection.java:219)
      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:140)
      ... 31 more

      1. derby-3709_p1.diff.txt
        0.9 kB
        Ole Solberg
      2. derby-3709_p1-v2.diff.txt
        1 kB
        Ole Solberg

        Issue Links

          Activity

          Hide
          V.Narayanan added a comment -

          I remember while working on 3617 thinking that this might be because the
          tests call failover immediately after a start master, this results in failover
          being called before replication can be booted completely. I will take a closer
          look at this over the weekend, unless someone beats me to it.

          Show
          V.Narayanan added a comment - I remember while working on 3617 thinking that this might be because the tests call failover immediately after a start master, this results in failover being called before replication can be booted completely. I will take a closer look at this over the weekend, unless someone beats me to it.
          Hide
          Ole Solberg added a comment -

          I think DERBY-3632 patch derby-3632_p1.diff.txt might "solve"/bypass the main problem here: that failover is attempted before replication is ready.

          The test should however also catch the unexpected exception so that the failure is not hidden: I will upload a patch for this.

          Show
          Ole Solberg added a comment - I think DERBY-3632 patch derby-3632_p1.diff.txt might "solve"/bypass the main problem here: that failover is attempted before replication is ready. The test should however also catch the unexpected exception so that the failure is not hidden: I will upload a patch for this.
          Hide
          Ole Solberg added a comment -

          Catch the unexpected exception so that the failure is not hidden.

          Show
          Ole Solberg added a comment - Catch the unexpected exception so that the failure is not hidden.
          Hide
          V.Narayanan added a comment -

          1) Can't we just leave the 'else' and the catch(Exception ex) parts since the method is already
          throwing an Exception?
          2) I am not sure this usage assertTrue(msg, false); is right, I guess the aim is to print msg all the time.
          Do we need to use assertTrue in this case?

          Also, I will get 3632 in first and then switch to this issue.

          Show
          V.Narayanan added a comment - 1) Can't we just leave the 'else' and the catch(Exception ex) parts since the method is already throwing an Exception? 2) I am not sure this usage assertTrue(msg, false); is right, I guess the aim is to print msg all the time. Do we need to use assertTrue in this case? Also, I will get 3632 in first and then switch to this issue.
          Hide
          Knut Anders Hatlen added a comment -

          Hi Narayanan,

          1) I agree. The if/else part could probably be replaced with a call to BaseJDBCTestCase.assertSQLState(), and the "catch (Exception e)" part could probably be removed.

          2) I think you're right. assertTrue(msg, false) should be replaced with fail(msg). And if we don't catch the exceptions, as you suggested in (1), we don't need that call at all.

          Show
          Knut Anders Hatlen added a comment - Hi Narayanan, 1) I agree. The if/else part could probably be replaced with a call to BaseJDBCTestCase.assertSQLState(), and the "catch (Exception e)" part could probably be removed. 2) I think you're right. assertTrue(msg, false) should be replaced with fail(msg). And if we don't catch the exceptions, as you suggested in (1), we don't need that call at all.
          Hide
          Ole Solberg added a comment -

          You are of course right, on both 1) and 2).
          This patch should take care of your suggested simplification.
          Thanks for catching this!

          ReplicationSuite ran OK with this patch.

          Show
          Ole Solberg added a comment - You are of course right, on both 1) and 2). This patch should take care of your suggested simplification. Thanks for catching this! ReplicationSuite ran OK with this patch.
          Hide
          V.Narayanan added a comment - - edited

          Thank you for the patch Ole! Shall run tests and commit tonight or early tomorrow morning.
          I have my hands full now (sorry that I can't commit this immediately)! Also should this change be reflected in the 10.4 branch also?

          Show
          V.Narayanan added a comment - - edited Thank you for the patch Ole! Shall run tests and commit tonight or early tomorrow morning. I have my hands full now (sorry that I can't commit this immediately)! Also should this change be reflected in the 10.4 branch also?
          Hide
          Ole Solberg added a comment -

          Yes, this should be merged to 10.4 also (derby-3632_p1.diff.txt + derby-3709_p1-v2.diff.txt).
          Thanks for handling this Narayanan!

          Show
          Ole Solberg added a comment - Yes, this should be merged to 10.4 also (derby-3632_p1.diff.txt + derby-3709_p1-v2.diff.txt). Thanks for handling this Narayanan!
          Hide
          V.Narayanan added a comment - - edited

          Thank you for the patch Ole

          I had two unrelated failures while running these tests

          Sending java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/ReplicationRun.java
          Transmitting file data .
          Committed revision 666006.

          Will merge it to 10.4 after running tests

          Show
          V.Narayanan added a comment - - edited Thank you for the patch Ole I had two unrelated failures while running these tests Sending java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/ReplicationRun.java Transmitting file data . Committed revision 666006. Will merge it to 10.4 after running tests
          Hide
          V.Narayanan added a comment -

          merged with 10.4. The tests in my environment were blubbering incoherently as usual :-/

          Sending java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/ReplicationRun.java
          Transmitting file data .
          Committed revision 666631.

          Show
          V.Narayanan added a comment - merged with 10.4. The tests in my environment were blubbering incoherently as usual :-/ Sending java/testing/org/apache/derbyTesting/functionTests/tests/replicationTests/ReplicationRun.java Transmitting file data . Committed revision 666631.
          Hide
          Ole Solberg added a comment -

          Patch has been applied (trunk and merged to 10.4).

          Show
          Ole Solberg added a comment - Patch has been applied (trunk and merged to 10.4).
          Hide
          Rick Hillegas added a comment -

          Marking as Fix Version 10.4.2 because the fix has been ported to the 10.4 branch.

          Show
          Rick Hillegas added a comment - Marking as Fix Version 10.4.2 because the fix has been ported to the 10.4 branch.
          Hide
          Rick Hillegas added a comment -

          Can this issue be marked as resolved now?

          Show
          Rick Hillegas added a comment - Can this issue be marked as resolved now?
          Hide
          Ole Solberg added a comment -

          Resolving: applied to trunk and 10.4.

          Show
          Ole Solberg added a comment - Resolving: applied to trunk and 10.4.

            People

            • Assignee:
              Ole Solberg
              Reporter:
              Knut Anders Hatlen
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development