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] [Updated] (DERBY-6092) testPositionAgressive(org.apache.derbyTesting.functionTests.tests.jdbcapi.BlobClob4BlobTest)j fails with : 'The handle is invalid.: java.io.IOException'.
Date Tue, 09 Apr 2013 09:54:16 GMT

     [ https://issues.apache.org/jira/browse/DERBY-6092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Knut Anders Hatlen updated DERBY-6092:
--------------------------------------

    Attachment: d6092-1a-reorder-cleanup.diff

I think this problem could be avoided without introducing more synchronization by reordering
how the finalizer performs the cleanup. See the attached patch d6092-1a-reorder-cleanup.diff.

The patch makes the finalizer's cleanup code remove the LOBFile from the list of open files
before attempting to close it. This way, when commit or rollback calls clearLOBMapping(),
it won't find the file in the list if the finalizer is about to close it, and it won't attempt
to close it a second time.

Conversely, if clearLOBMapping() is about to close the file when the finalizer is run, the
finalizer will have to wait until it's done before it can proceed with removing the file from
the list (because clearLOBMapping() synchronizes on the list while it iterates over it). Since
the patch makes the finalizer wait with closing the file until it's removed from the list,
it won't try to close it until after clearLOBMapping() is done closing it. In this case, the
file will still be closed twice, but it won't be closed twice concurrently, and the bug is
avoided.

On Java 6 and newer the patch shouldn't be necessary for correctness. However, it makes it
slightly less likely that unnecessary work (that is, double closing) is done, and it doesn't
increase code complexity, so I think it's an improvement regardless of the JVM bug it attempts
to work around.

I'm running the full regression test suite on the patch now.

It would be good if someone who is able to reproduce the problem could check if the patch
helps.
                
> testPositionAgressive(org.apache.derbyTesting.functionTests.tests.jdbcapi.BlobClob4BlobTest)j
fails with : 'The handle is invalid.: java.io.IOException'.
> ---------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-6092
>                 URL: https://issues.apache.org/jira/browse/DERBY-6092
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 10.10.1.2, 10.11.0.0
>         Environment: IBM 1,5 
> java.specification.version: 1.5
> java.runtime.version: pwi32dev-20121015 (SR15 )
> java.fullversion: J2RE 1.5.0 IBM J9 2.3 Windows XP x86-32 j9vmwi3223-20121012 (JIT enabled)
> J9VM - 20121010_124616_lHdSMr
> JIT  - 20120914_26053ifx1_r8
> GC   - 20120911_AA
>            Reporter: Kathey Marsden
>            Priority: Blocker
>         Attachments: CloseRAF.java, d6092-1a-reorder-cleanup.diff, derby-6092_noorderby.diff
>
>
> There was 1 error:
> http://people.apache.org/~myrnavl/derby_test_results/main/windows/testlog/ibm15/1449432-suites.All_diff.txt
> 1) testPositionAgressive(org.apache.derbyTesting.functionTests.tests.jdbcapi.BlobClob4BlobTest)java.sql.SQLException:
Java exception: 'The handle is invalid.: java.io.IOException'.
> 	at org.apache.derby.impl.jdbc.SQLExceptionFactory.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.EmbedConnection.clearLOBMapping(Unknown Source)
> 	at org.apache.derby.impl.jdbc.EmbedConnection.commit(Unknown Source)
> 	at org.apache.derbyTesting.junit.BaseJDBCTestCase.commit(BaseJDBCTestCase.java:393)
> 	at org.apache.derbyTesting.functionTests.tests.jdbcapi.BlobClob4BlobTest.testPositionAgressive(BlobClob4BlobTest.java:1070)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:79)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117)
> 	at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:424)
> 	at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:441)
> 	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)
> 	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)
> 	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: java.io.IOException: The handle is invalid.
> 	at java.io.RandomAccessFile.close0(Native Method)
> 	at java.io.RandomAccessFile.close(RandomAccessFile.java:573)
> 	at org.apache.derby.impl.jdbc.LOBFile.close(Unknown Source)
> 	at org.apache.derby.impl.jdbc.EncryptedLOBFile.close(Unknown Source)
> 	... 53 more

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message