Derby
  1. Derby
  2. DERBY-5158

Incomprehensible error message on client if attempting rollback after database has been shut down.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 10.8.2.2, 10.9.1.0
    • Component/s: None
    • Labels:
      None
    • Issue & fix info:
      Repro attached
    • Bug behavior facts:
      Embedded/Client difference

      Description

      Cf the attached repro: when performing the rollback after the database has been shutdown, we see this error:

      There was 1 error:
      1) testShutdown(org.apache.derbyTesting.functionTests.tests.store.Foo)java.sql.SQLNonTransientConnectionException: Network protocol exception: actual code point, 4,692, does not match expected code point, 9,224. The connection has been terminated.
      at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71)
      at org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:358)
      at org.apache.derby.client.am.Connection.rollback(Connection.java:659)
      at org.apache.derbyTesting.junit.BaseJDBCTestCase.rollback(BaseJDBCTestCase.java:387)
      at org.apache.derbyTesting.functionTests.tests.store.Foo.testShutdown(Foo.java:100)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:112)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
      at junit.extensions.TestSetup.run(TestSetup.java:25)
      at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
      at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
      at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
      at junit.extensions.TestSetup.run(TestSetup.java:25)
      Caused by: org.apache.derby.client.am.DisconnectException: Network protocol exception: actual code point, 4,692, does not match expected code point, 9,224. The connection has been terminated.
      at org.apache.derby.client.net.Reply.parseLengthAndMatchCodePoint(Reply.java:1075)
      at org.apache.derby.client.net.NetConnectionReply.parseSQLCARD(NetConnectionReply.java:2572)
      at org.apache.derby.client.net.NetConnectionReply.parseRDBRLLBCKreply(NetConnectionReply.java:219)
      at org.apache.derby.client.net.NetConnectionReply.readLocalRollback(NetConnectionReply.java:141)
      at org.apache.derby.client.net.ConnectionReply.readLocalRollback(ConnectionReply.java:48)
      at org.apache.derby.client.net.NetConnection.readLocalRollback_(NetConnection.java:1515)
      at org.apache.derby.client.am.Connection.readRollback(Connection.java:707)
      at org.apache.derby.client.am.Connection.flowRollback(Connection.java:690)
      at org.apache.derby.client.am.Connection.rollback(Connection.java:655)
      ... 29 more

      1. DERBY-5158a.diff
        6 kB
        Dag H. Wanvik
      2. DERBY-5158a.stat
        0.2 kB
        Dag H. Wanvik
      3. DERBY-5158b.diff
        7 kB
        Dag H. Wanvik
      4. DERBY-5158b.stat
        0.2 kB
        Dag H. Wanvik
      5. Derby5158Repro.java
        3 kB
        Dag H. Wanvik

        Issue Links

          Activity

          Dag H. Wanvik created issue -
          Hide
          Dag H. Wanvik added a comment - - edited

          In contrast, if we attempt to execute a query (rather than a rollback), we see the more understandable error stack trace whose ultimate cause is given as "No current connection":

          1) testShutdown(org.apache.derbyTesting.functionTests.tests.store.Foo)java.sql.SQLNonTransientConnectionException: A network protocol error was encountered and the connection has been terminated: the requested command encountered an unarchitected and implementation-specific condition for which there was no architected message (additional information may be available in the derby.log file on the server)
          at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71)
          at org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:358)
          at org.apache.derby.client.am.Statement.executeQuery(Statement.java:486)
          at org.apache.derbyTesting.functionTests.tests.store.Foo.testShutdown(Foo.java:102)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:112)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
          at junit.extensions.TestSetup.run(TestSetup.java:25)
          at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
          at junit.extensions.TestSetup.run(TestSetup.java:25)
          Caused by: org.apache.derby.client.am.DisconnectException: A network protocol error was encountered and the connection has been terminated: the requested command encountered an unarchitected and implementation-specific condition for which there was no architected message (additional information may be available in the derby.log file on the server)
          at org.apache.derby.client.net.NetConnectionReply.parseCMDCHKRM(NetConnectionReply.java:882)
          at org.apache.derby.client.net.NetStatementReply.parsePrepareError(NetStatementReply.java:550)
          at org.apache.derby.client.net.NetStatementReply.parsePRPSQLSTTreply(NetStatementReply.java:144)
          at org.apache.derby.client.net.NetStatementReply.readPrepareDescribeOutput(NetStatementReply.java:53)
          at org.apache.derby.client.net.StatementReply.readPrepareDescribeOutput(StatementReply.java:40)
          at org.apache.derby.client.net.NetStatement.readPrepareDescribeOutput_(NetStatement.java:138)
          at org.apache.derby.client.am.Statement.readPrepareDescribeOutput(Statement.java:1443)
          at org.apache.derby.client.am.Statement.flowExecute(Statement.java:2117)
          at org.apache.derby.client.am.Statement.executeQueryX(Statement.java:492)
          at org.apache.derby.client.am.Statement.executeQuery(Statement.java:477)
          ... 28 more
          Caused by: java.lang.Exception: No current connection.

          Show
          Dag H. Wanvik added a comment - - edited In contrast, if we attempt to execute a query (rather than a rollback), we see the more understandable error stack trace whose ultimate cause is given as "No current connection": 1) testShutdown(org.apache.derbyTesting.functionTests.tests.store.Foo)java.sql.SQLNonTransientConnectionException: A network protocol error was encountered and the connection has been terminated: the requested command encountered an unarchitected and implementation-specific condition for which there was no architected message (additional information may be available in the derby.log file on the server) at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71) at org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:358) at org.apache.derby.client.am.Statement.executeQuery(Statement.java:486) at org.apache.derbyTesting.functionTests.tests.store.Foo.testShutdown(Foo.java:102) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:112) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) Caused by: org.apache.derby.client.am.DisconnectException: A network protocol error was encountered and the connection has been terminated: the requested command encountered an unarchitected and implementation-specific condition for which there was no architected message (additional information may be available in the derby.log file on the server) at org.apache.derby.client.net.NetConnectionReply.parseCMDCHKRM(NetConnectionReply.java:882) at org.apache.derby.client.net.NetStatementReply.parsePrepareError(NetStatementReply.java:550) at org.apache.derby.client.net.NetStatementReply.parsePRPSQLSTTreply(NetStatementReply.java:144) at org.apache.derby.client.net.NetStatementReply.readPrepareDescribeOutput(NetStatementReply.java:53) at org.apache.derby.client.net.StatementReply.readPrepareDescribeOutput(StatementReply.java:40) at org.apache.derby.client.net.NetStatement.readPrepareDescribeOutput_(NetStatement.java:138) at org.apache.derby.client.am.Statement.readPrepareDescribeOutput(Statement.java:1443) at org.apache.derby.client.am.Statement.flowExecute(Statement.java:2117) at org.apache.derby.client.am.Statement.executeQueryX(Statement.java:492) at org.apache.derby.client.am.Statement.executeQuery(Statement.java:477) ... 28 more Caused by: java.lang.Exception: No current connection.
          Dag H. Wanvik made changes -
          Field Original Value New Value
          Attachment Derby5158Repro.java [ 12474788 ]
          Hide
          Dag H. Wanvik added a comment -

          The problem seems to be the following:

          In DRDAConnThread#processCommands we have this code for rollback:

          case CodePoint.RDBCMM:
          try

          {..}

          catch (SQLException e)

          { writer.clearDSSesBackToMark(writerMark); // Even in case of error, we have to write the ENDUOWRM. writeENDUOWRM(COMMIT); writeSQLCARDs(e, 0); errorInChain(e); }

          i.e. we send an ENDUOWRM, then the writeSQLCARDs will send a CMDCHKRM (severe error), then
          the SQLCARD.

          However, on the client side, we see this code to handle reply for rollback:

          private void parseRDBRLLBCKreply(ConnectionCallbackInterface connection)
          throws DisconnectException {
          int peekCP = parseTypdefsOrMgrlvlovrs();
          if (peekCP != CodePoint.ENDUOWRM)

          { <---------------- Note! parseRollbackError(); return; }

          parseENDUOWRM(connection);
          peekCP = parseTypdefsOrMgrlvlovrs();

          NetSqlca netSqlca = parseSQLCARD(null);
          connection.completeSqlca(netSqlca);
          }

          that is, parseRollbackError is only executed iff ENDUOWRM is not
          returned. But we just saw that the server side sent a ENDUOWRM even
          under an error condition. So, the client will happily
          parseENDUOWRM and then expect SQLCARD when there is actually a CMDCHKRM
          waiting. hence the code point error. I am not sure which side is
          correct here, but maybe you DRDA experts can help out

          Show
          Dag H. Wanvik added a comment - The problem seems to be the following: In DRDAConnThread#processCommands we have this code for rollback: case CodePoint.RDBCMM: try {..} catch (SQLException e) { writer.clearDSSesBackToMark(writerMark); // Even in case of error, we have to write the ENDUOWRM. writeENDUOWRM(COMMIT); writeSQLCARDs(e, 0); errorInChain(e); } i.e. we send an ENDUOWRM, then the writeSQLCARDs will send a CMDCHKRM (severe error), then the SQLCARD. However, on the client side, we see this code to handle reply for rollback: private void parseRDBRLLBCKreply(ConnectionCallbackInterface connection) throws DisconnectException { int peekCP = parseTypdefsOrMgrlvlovrs(); if (peekCP != CodePoint.ENDUOWRM) { <---------------- Note! parseRollbackError(); return; } parseENDUOWRM(connection); peekCP = parseTypdefsOrMgrlvlovrs(); NetSqlca netSqlca = parseSQLCARD(null); connection.completeSqlca(netSqlca); } that is, parseRollbackError is only executed iff ENDUOWRM is not returned. But we just saw that the server side sent a ENDUOWRM even under an error condition. So, the client will happily parseENDUOWRM and then expect SQLCARD when there is actually a CMDCHKRM waiting. hence the code point error. I am not sure which side is correct here, but maybe you DRDA experts can help out
          Hide
          Dag H. Wanvik added a comment -

          Btw, code point 4692 (0x1254) is CMDCHKRM, 9224 (0x2408) is SQLCARD.

          Show
          Dag H. Wanvik added a comment - Btw, code point 4692 (0x1254) is CMDCHKRM, 9224 (0x2408) is SQLCARD.
          Hide
          Dag H. Wanvik added a comment -

          A commit in the same location as the rollback, does not throw.

          Show
          Dag H. Wanvik added a comment - A commit in the same location as the rollback, does not throw.
          Hide
          Dag H. Wanvik added a comment - - edited

          The reason the commit does not throw is that the repro did not switch off autocommit, so the commit is never sent to the server (DERBY-4653 optimization). The rollback is still flowed, cf. DERBY-4687.

          Show
          Dag H. Wanvik added a comment - - edited The reason the commit does not throw is that the repro did not switch off autocommit, so the commit is never sent to the server ( DERBY-4653 optimization). The rollback is still flowed, cf. DERBY-4687 .
          Hide
          Dag H. Wanvik added a comment -

          By adding setAUtoCommit(false) in Derby5158Repro#setUp, we see the issue also for commit.

          Show
          Dag H. Wanvik added a comment - By adding setAUtoCommit(false) in Derby5158Repro#setUp, we see the issue also for commit.
          Hide
          Dag H. Wanvik added a comment -

          Attaching a patch, DERBY-5158a, which corrects the protocol code on the client side to cater for ENDUOWRM even in the error case (as sent by the server). Looking at the DRDA standard, I didn't quite manage to satisfy myself that this is the correct behavior, but almost: section 7.5 Commit/Rollback processing, where CR2 says:

          "Application servers using remote unit of work protocols and application servers using distributed unit of work but not protected by a sync point manager must inform the application requester when the current unit of work at the application server ends as a result of a commit or rollback request by an application or application requester request. This information is returned in the RPYDSS, containing the ENDUOWRM reply message."

          So, does the above apply when an error happens (the database has already been shut down, so no connection can be established)? In a way, the "remote unit of work" is definitely ended, so...

          Note that the (new) error stack trace is still different than with the embedded driver, since there the 08003 will be directly reported as the error (not wrapped in 06006 as shown below for the client side).

          I added a new test, Derby5158Test, not being sure where to put this new test case (I didn't find any specific tests for commit/rollback), if you know a better placement for it, let me know! I could always put it in ShutdownDatabaseTest, I guess..

          Running regressions.

          With this new code, the following error stack dump can be seen on the client side, which shows that the underlyinc cause of the error is 08003. "No current connection".

          java.sql.SQLNonTransientConnectionException: A network protocol error was encountered and the connection has been terminated: the requested command encountered an unarchitected and implementation-specific condition for which there was no architected message (additional information may be available in the derby.log file on the server)
          at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71)
          at org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:358)
          at org.apache.derby.client.am.Connection.rollback(Connection.java:659)
          at org.apache.derbyTesting.functionTests.tests.jdbcapi.Derby5158Test.testShutdown(Derby5158Test.java:71)
          at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
          at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:112)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
          at junit.extensions.TestSetup.run(TestSetup.java:25)
          at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
          at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
          at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
          at junit.extensions.TestSetup.run(TestSetup.java:25)
          Caused by: org.apache.derby.client.am.DisconnectException: A network protocol error was encountered and the connection has been terminated: the requested command encountered an unarchitected and implementation-specific condition for which there was no architected message (additional information may be available in the derby.log file on the server)
          at org.apache.derby.client.net.NetConnectionReply.parseCMDCHKRM(NetConnectionReply.java:880)
          at org.apache.derby.client.net.NetConnectionReply.parseRollbackError(NetConnectionReply.java:359)
          at org.apache.derby.client.net.NetConnectionReply.parseRDBRLLBCKreply(NetConnectionReply.java:216)
          at org.apache.derby.client.net.NetConnectionReply.readLocalRollback(NetConnectionReply.java:141)
          at org.apache.derby.client.net.ConnectionReply.readLocalRollback(ConnectionReply.java:48)
          at org.apache.derby.client.net.NetConnection.readLocalRollback_(NetConnection.java:1515)
          at org.apache.derby.client.am.Connection.readRollback(Connection.java:707)
          at org.apache.derby.client.am.Connection.flowRollback(Connection.java:690)
          at org.apache.derby.client.am.Connection.rollback(Connection.java:655)
          ... 28 more
          Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: -1, SQLSTATE: 08003, SQLERRMC: No current connection.
          ... 37 more

          Show
          Dag H. Wanvik added a comment - Attaching a patch, DERBY-5158 a, which corrects the protocol code on the client side to cater for ENDUOWRM even in the error case (as sent by the server). Looking at the DRDA standard, I didn't quite manage to satisfy myself that this is the correct behavior, but almost: section 7.5 Commit/Rollback processing, where CR2 says: "Application servers using remote unit of work protocols and application servers using distributed unit of work but not protected by a sync point manager must inform the application requester when the current unit of work at the application server ends as a result of a commit or rollback request by an application or application requester request. This information is returned in the RPYDSS, containing the ENDUOWRM reply message." So, does the above apply when an error happens (the database has already been shut down, so no connection can be established)? In a way, the "remote unit of work" is definitely ended, so... Note that the (new) error stack trace is still different than with the embedded driver, since there the 08003 will be directly reported as the error (not wrapped in 06006 as shown below for the client side). I added a new test, Derby5158Test, not being sure where to put this new test case (I didn't find any specific tests for commit/rollback), if you know a better placement for it, let me know! I could always put it in ShutdownDatabaseTest, I guess.. Running regressions. With this new code, the following error stack dump can be seen on the client side, which shows that the underlyinc cause of the error is 08003. "No current connection". java.sql.SQLNonTransientConnectionException: A network protocol error was encountered and the connection has been terminated: the requested command encountered an unarchitected and implementation-specific condition for which there was no architected message (additional information may be available in the derby.log file on the server) at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(SQLExceptionFactory40.java:71) at org.apache.derby.client.am.SqlException.getSQLException(SqlException.java:358) at org.apache.derby.client.am.Connection.rollback(Connection.java:659) at org.apache.derbyTesting.functionTests.tests.jdbcapi.Derby5158Test.testShutdown(Derby5158Test.java:71) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:112) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24) at junit.extensions.TestSetup$1.protect(TestSetup.java:21) at junit.extensions.TestSetup.run(TestSetup.java:25) Caused by: org.apache.derby.client.am.DisconnectException: A network protocol error was encountered and the connection has been terminated: the requested command encountered an unarchitected and implementation-specific condition for which there was no architected message (additional information may be available in the derby.log file on the server) at org.apache.derby.client.net.NetConnectionReply.parseCMDCHKRM(NetConnectionReply.java:880) at org.apache.derby.client.net.NetConnectionReply.parseRollbackError(NetConnectionReply.java:359) at org.apache.derby.client.net.NetConnectionReply.parseRDBRLLBCKreply(NetConnectionReply.java:216) at org.apache.derby.client.net.NetConnectionReply.readLocalRollback(NetConnectionReply.java:141) at org.apache.derby.client.net.ConnectionReply.readLocalRollback(ConnectionReply.java:48) at org.apache.derby.client.net.NetConnection.readLocalRollback_(NetConnection.java:1515) at org.apache.derby.client.am.Connection.readRollback(Connection.java:707) at org.apache.derby.client.am.Connection.flowRollback(Connection.java:690) at org.apache.derby.client.am.Connection.rollback(Connection.java:655) ... 28 more Caused by: org.apache.derby.client.am.SqlException: DERBY SQL error: SQLCODE: -1, SQLSTATE: 08003, SQLERRMC: No current connection. ... 37 more
          Dag H. Wanvik made changes -
          Attachment DERBY-5158a.diff [ 12475381 ]
          Attachment DERBY-5158a.stat [ 12475382 ]
          Dag H. Wanvik made changes -
          Assignee Dag H. Wanvik [ dagw ]
          Dag H. Wanvik made changes -
          Bug behavior facts [Embedded/Client difference]
          Issue & fix info [Patch Available]
          Dag H. Wanvik made changes -
          Issue & fix info [Patch Available] [Patch Available, Repro attached]
          Hide
          Bryan Pendleton added a comment -

          I find your reading of the documents reasonable, and the behavior of the system with
          your change is clearly superior to the prior behavior. Having "No current connection"
          appear in the stack trace (which your change does) should provide adequate information
          for a motivated developer to figure out that they've attempted a rollback but are
          not currently connected to the database, which seems like the basic goal of your fix.

          So, +1 from me!

          Show
          Bryan Pendleton added a comment - I find your reading of the documents reasonable, and the behavior of the system with your change is clearly superior to the prior behavior. Having "No current connection" appear in the stack trace (which your change does) should provide adequate information for a motivated developer to figure out that they've attempted a rollback but are not currently connected to the database, which seems like the basic goal of your fix. So, +1 from me!
          Hide
          Dag H. Wanvik added a comment -

          Thanks, Bryan! Yes, that was my goal indeed. Regressions ran ok.

          Show
          Dag H. Wanvik added a comment - Thanks, Bryan! Yes, that was my goal indeed. Regressions ran ok.
          Dag H. Wanvik made changes -
          Link This issue relates to DERBY-2477 [ DERBY-2477 ]
          Hide
          Dag H. Wanvik added a comment -

          Uploading a new version of the patch, which improves the test a bit: we now make sure to do some work before closing down the database, since otherwise the client short circuits the commit (if it knows nothing happened yet on this connection). Rollback does not do this, cf. DERBY-4653.(I did not notice this optimization in the first version, but saw it when instrumenting it for verification.)

          I did not move the test into ShutdownDatabaseTest, because that test does not yet run with client/server due to DERBY-2477. Linked this issue to that also.

          Show
          Dag H. Wanvik added a comment - Uploading a new version of the patch, which improves the test a bit: we now make sure to do some work before closing down the database, since otherwise the client short circuits the commit (if it knows nothing happened yet on this connection). Rollback does not do this, cf. DERBY-4653 .(I did not notice this optimization in the first version, but saw it when instrumenting it for verification.) I did not move the test into ShutdownDatabaseTest, because that test does not yet run with client/server due to DERBY-2477 . Linked this issue to that also.
          Dag H. Wanvik made changes -
          Attachment DERBY-5158b.diff [ 12475543 ]
          Attachment DERBY-5158b.stat [ 12475544 ]
          Hide
          Dag H. Wanvik added a comment -

          Re-ran suites.All ok with version "b", modulo a new instance of DERBY-5003.

          Show
          Dag H. Wanvik added a comment - Re-ran suites.All ok with version "b", modulo a new instance of DERBY-5003 .
          Hide
          Dag H. Wanvik added a comment -

          Committed as svn 1089795, resolving.

          Show
          Dag H. Wanvik added a comment - Committed as svn 1089795, resolving.
          Dag H. Wanvik made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Issue & fix info [Repro attached, Patch Available] [Repro attached]
          Resolution Fixed [ 1 ]
          Hide
          Kathey Marsden added a comment -

          Should we consider this for backport?

          Show
          Kathey Marsden added a comment - Should we consider this for backport?
          Kathey Marsden made changes -
          Fix Version/s 10.9.0.0 [ 12316344 ]
          Hide
          Dag H. Wanvik added a comment -

          I think it would be fine if you think it is important enough.

          Show
          Dag H. Wanvik added a comment - I think it would be fine if you think it is important enough.
          Hide
          Myrna van Lunteren added a comment -

          Reopen for backport to 10.8

          Show
          Myrna van Lunteren added a comment - Reopen for backport to 10.8
          Myrna van Lunteren made changes -
          Resolution Fixed [ 1 ]
          Status Resolved [ 5 ] Reopened [ 4 ]
          Hide
          Myrna van Lunteren added a comment -

          backported the fix to 10.8 with revision 1160516.

          Show
          Myrna van Lunteren added a comment - backported the fix to 10.8 with revision 1160516.
          Myrna van Lunteren made changes -
          Status Reopened [ 4 ] Closed [ 6 ]
          Fix Version/s 10.8.1.6 [ 12316676 ]
          Resolution Fixed [ 1 ]
          Myrna van Lunteren made changes -
          Fix Version/s 10.8.2.0 [ 12317955 ]
          Fix Version/s 10.8.1.6 [ 12316676 ]
          Myrna van Lunteren made changes -
          Fix Version/s 10.8.2.2 [ 12317968 ]
          Fix Version/s 10.8.2.0 [ 12317955 ]
          Gavin made changes -
          Workflow jira [ 12608866 ] Default workflow, editable Closed status [ 12801211 ]
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Resolved Resolved
          9d 17h 19m 1 Dag H. Wanvik 07/Apr/11 11:01
          Resolved Resolved Reopened Reopened
          137d 12h 57m 1 Myrna van Lunteren 22/Aug/11 23:58
          Reopened Reopened Closed Closed
          1h 53m 1 Myrna van Lunteren 23/Aug/11 01:51

            People

            • Assignee:
              Dag H. Wanvik
              Reporter:
              Dag H. Wanvik
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development