[
https://issues.apache.org/jira/browse/DERBY-5113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006156#comment-13006156
]
Knut Anders Hatlen commented on DERBY-5113:
-------------------------------------------
We have two bugs here. One test bug and one product bug.
The product bug is that EmbedBlob.truncate() doesn't reset the position of the
underlying stream before copying the first N bytes to a new location. If the
stream position has been altered by a call to another method (like
EmbedBlob.getBytes() here), the copying happens on the wrong position, and we
may see this exception being raised. This bug is only seen if the Blob is in
stream format, which typically means that the Blob must have been fetched from
store and its size must be > 32K.
The product bug doesn't explain why it fails intermittently on Java 7, though,
and it isn't reproducible when running the test standalone. The length of the
Blob used in the failing test is only about 5K, so the Blob should be
materialized and not be represented as a stream, and the buggy code path
shouldn't be taken. The only reason I can think of that the buggy code path
should be taken here, is if the page size is smaller than 5K, which would make
store return the Blob as a stream rather than a fully materialized byte array.
And if the test is run with the derby.storage.pageSize property set to 4096, it
does indeed fail consistently.
Looking at tests that set the derby.storage.pageSize property, I found that
store.AccessTest sets the property, but doesn't always reset it. If its test
cases runs in the order in which they appear in the source file, the property
will be reset. But the order of the test cases is not guaranteed, and the
latest builds of Java 7 tend to run the test cases in a different order than
other JVMs. If one of the test cases that don't reset the property runs last, a
smaller page size value may survive in the database until BlobSetMethodsTest
runs, and we'll see this failure.
> Intermittent failure in BlobSetMethodsTest on Java 7: Unable to set stream:
> 'Reached EOF prematurely; expected 1,024, got 0.'
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-5113
> URL: https://issues.apache.org/jira/browse/DERBY-5113
> Project: Derby
> Issue Type: Bug
> Components: JDBC, Test
> Affects Versions: 10.8.0.0
> Environment: Solaris 10 and Windows
> Java(TM) SE Runtime Environment (build 1.7.0-ea-b131)
> Reporter: Knut Anders Hatlen
> Attachments: reporting.diff
>
>
> Not sure if this is a test issue, a product issue or a JVM issue. It started
> happening when JDK 7 was upgraded from b116 to b131 in the nightly tests. I
> haven't been able to reproduce the failure in my environment, but it happens
> frequently in the nightly testing. For example here:
> http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.7/testing/testlog/sol/1078053-suitesAll_diff.txt
> 19)
> testSetBytesLargeBlob(org.apache.derbyTesting.functionTests.tests.jdbc4.BlobSetMethodsTest)java.sql.SQLException:
> Unable to set stream: 'Reached EOF prematurely; expected 1,024, got 0.'.
> 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.newEmbedSQLException(Unknown Source)
> at org.apache.derby.impl.jdbc.Util.setStreamFailure(Unknown Source)
> at org.apache.derby.impl.jdbc.EmbedBlob.truncate(Unknown Source)
> at
> org.apache.derbyTesting.functionTests.tests.jdbc4.BlobSetMethodsTest.testSetBytesLargeBlob(BlobSetMethodsTest.java:102)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 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)
> Caused by: java.sql.SQLException: Unable to set stream: 'Reached EOF
> prematurely; expected 1,024, got 0.'.
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(Unknown Source)
> at
> org.apache.derby.impl.jdbc.SQLExceptionFactory40.wrapArgsForTransportAcrossDRDA(Unknown
> Source)
> The problem does not appear to be the reordering of the test cases that we've
> seen in many other tests when running on Java 7 b131. According to the traces
> printed to the test log (for example in the above mentioned URL), this
> failure is also seen in the cases where the test cases run in the same order
> as on most other platforms.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
