db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-5113) Intermittent failure in BlobSetMethodsTest on Java 7: Unable to set stream: 'Reached EOF prematurely; expected 1,024, got 0.'
Date Sun, 13 Mar 2011 08:13:59 GMT

    [ 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

Mime
View raw message