[
https://issues.apache.org/jira/browse/DERBY-4122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12694932#action_12694932
]
Kristian Waagan commented on DERBY-4122:
----------------------------------------
Knut, I'm working on a new patch. The following items (taken from your
comments) will be addressed:
o remove BUFSIZE (and adjust code where required)
o remove shrink logic
o move and/or add more comments about the magic number 6
o copy optimization
o NPE possibility in root cause determination code
o rewrite if in SQLClob
Then some comments on some of the other items:
> Do we need to separate between MARK_UNSET and EXCEEDED_MARK_LIMIT?
No, only for more specific error reporting, I think.
> In readExternal() we now subtract the header length from the byte length
> before we pass it to super.readExternal(). As far as I can see, this is a
> code path taken in normal operation too, not only in soft upgrade. Was this a
> bug that was possible to see when not running with a soft upgraded db?
No, it should not happen in a fresh 10.5 database. It can happen in soft and
hard upgrade.
The reason why it doesn't happen in a fresh database, is that all lengths are
stored as character counts.
> Both SQLClob and ReaderToUTF8Stream have code where they use Math.max(0, x-y)
> to prevent that an argument goes negative. I'm not sure I see why the
> arguments will go negative, and isn't there a chance that we're hiding real
> bugs this way?
The argument in SQLClob will go negative when the stored length in the byte
header is 0. Since the header length is still two in this case, we get 0 - 2 =
-2. There is a slight chance we may hide a bug with this, but the bug will be
revealed when we actually try to read the value. In principle, what we're
saying here is that if the length we obtained from the header is negative,
assume it is unknown.
I can try to rewrite the check so that it is easier to understand, and add some
comments.
In ReaderToUTF8Stream, the variable blen will be -1 the first time we fill the
buffer. Again, I'll rewrite or/and add a comment to make it easier to read the
code.
> ClassCastException in SQLClob when running in soft upgrade mode (10.4.2.0 ->
> 10.5.1.0)
> --------------------------------------------------------------------------------------
>
> Key: DERBY-4122
> URL: https://issues.apache.org/jira/browse/DERBY-4122
> Project: Derby
> Issue Type: Bug
> Components: Regression Test Failure
> Affects Versions: 10.5.1.0
> Environment: Windows Vista 64, Sun JDK 1.6.0_10, Junit 3.8.2
> Reporter: Suran Jayathilaka
> Assignee: Kristian Waagan
> Priority: Blocker
> Attachments: derby-4122-1a-incorrect_stream_positioning.diff,
> derby-4122-2a-bc4btest.diff, derby-4122-3a-classcast_fix.diff,
> derby-4122-3b-classcast_fix.diff, derby-4122-4a-classcast_fix_mark_reset.diff
>
>
> This bug was found when doing soft upgrade testing from Derby version
> 10.4.2.0 to 10.5.1.0 (RC1)
> Steps followed are as follows.
> 1. Run setEmbeddedCP.bat from version 10.4.2.0's bin folder
> 2. In a test folder run ij
> 3. create system/wombat database.
> ij> connect 'jdbc:derby:system/wombat;create=true';
> 4. exit ij
> 5. Copy the 10.5.1.0 derby jars (from lib folder) and the derbyTesting.jar
> from 10.4.2.0 to the test folder and set classpath with them (including junit
> and ORO)
> 6. Run suites.All
> java -Xmx512M -Xms512M -Dderby.tests.trace=true junit.textui.TestRunner
> org.apache.derbyTesting.functionTests.suites.All
> Result:
> Tests run: 10479, Failures: 56, Errors: 34
> The exception stack trace from a failed test follows.
> -------------------------------------------------------------------------------------------------------------
> 3)
> testClobInTriggerTable(org.apache.derbyTesting.functionTests.tests.lang.TriggerTest)java.sql.SQLException:
> Java exception: 'org.apache.derby.iapi.types.ReaderToUTF8Stream cannot be
> cast to org.apache.derby.iapi.types.Resetable: java.lang.ClassCastException'.
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory40.getSQLException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.Util.javaException(Unknown Source)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown
> Source)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown
> Source)
> at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown
> Source)
> at
> org.apache.derbyTesting.functionTests.tests.lang.TriggerTest.testClobInTriggerTable(TriggerTest.java:529)
> at
> org.apache.derbyTesting.functionTests.tests.lang.TriggerTest.testClobInTriggerTable(TriggerTest.java:451)
> 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:102)
> 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)
> Caused by: java.sql.SQLException: Java exception:
> 'org.apache.derby.iapi.types.ReaderToUTF8Stream cannot be cast to
> org.apache.derby.iapi.types.Resetable: java.lang.ClassCastException'.
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown
> Source)
> ... 39 more
> Caused by: java.lang.ClassCastException:
> org.apache.derby.iapi.types.ReaderToUTF8Stream cannot be cast to
> org.apache.derby.iapi.types.Resetable
> at org.apache.derby.iapi.types.SQLClob.rewindStream(Unknown Source)
> at org.apache.derby.iapi.types.SQLClob.readExternal(Unknown Source)
> at org.apache.derby.iapi.types.SQLChar.getString(Unknown Source)
> at org.apache.derby.iapi.types.SQLChar.loadStream(Unknown Source)
> at
> org.apache.derby.impl.sql.execute.UpdateResultSet.objectifyStream(Unknown
> Source)
> at
> org.apache.derby.impl.sql.execute.UpdateResultSet.collectAffectedRows(Unknown
> Source)
> at org.apache.derby.impl.sql.execute.UpdateResultSet.open(Unknown
> Source)
> at
> org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown Source)
> at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
> Source)
> ... 32 more
> ------------------------------------------------------------------------------------------------------------------
> When looking at the SVN revisions for SQLClob with Kathey Marsden, we found
> the following statement in revision # 738408, related to DERBY-3907, which
> might be related to this issue.
> "NOTE: Databases created with this revision (or later) containing Clobs,
> cannot be accessed by earlier trunk revisions."
> Patch file: derby-3907-7a3-use_new_header_format.diff
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
