[ 
https://issues.apache.org/jira/browse/DERBY-5223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030803#comment-13030803
 ] 

Dag H. Wanvik commented on DERBY-5223:
--------------------------------------

I instrumented this and retrieved the following stack trace which shows where 
Derby detected the interrupt, but failed to preserve the flag.
Notice that on the stack we have the frame:

    
GenericLanguageConnectionContext.initialize(GenericLanguageConnectionContext.java:401)

The variable interruptedException is set to null just *after* that call, which 
is clearly wrong: the null initialization happens too late since, in this case, 
the connection has seen an interrupt in the line above, i.e. 
"setDefaultSchema(initDefaultSchemaDescriptor());".

Hence, we lose the information that Derby has seen an interrupt and temporarily 
proceeded with the flag cleared (so that NIO can complete ok). On return from 
the connect call, the flag is thus never set back on again.

..java.lang.Exception: Stack trace
        at java.lang.Thread.dumpStack(Thread.java:1342)
        at 
org.apache.derby.iapi.util.InterruptStatus.setInterrupted(InterruptStatus.java:83)
        at 
org.apache.derby.impl.store.raw.data.BasePage.setExclusive(BasePage.java:1689)
        at 
org.apache.derby.impl.store.raw.data.BaseContainer.latchPage(BaseContainer.java:527)
        at 
org.apache.derby.impl.store.raw.data.FileContainer.latchPage(FileContainer.java:3530)
        at 
org.apache.derby.impl.store.raw.data.FileContainer.getUserPage(FileContainer.java:2549)
        at 
org.apache.derby.impl.store.raw.data.FileContainer.getPage(FileContainer.java:2591)
        at 
org.apache.derby.impl.store.raw.data.BaseContainerHandle.getPage(BaseContainerHandle.java:319)
        at 
org.apache.derby.impl.store.access.btree.ControlRow.get(ControlRow.java:833)
        at 
org.apache.derby.impl.store.access.btree.ControlRow.get(ControlRow.java:820)
        at 
org.apache.derby.impl.store.access.btree.BTreeScan.positionAtStartForForwardScan(BTreeScan.java:361)
        at 
org.apache.derby.impl.store.access.btree.BTreeForwardScan.positionAtStartPosition(BTreeForwardScan.java:70)
        at 
org.apache.derby.impl.store.access.btree.BTreeForwardScan.fetchRows(BTreeForwardScan.java:122)
        at 
org.apache.derby.impl.store.access.btree.BTreeScan.fetchNext(BTreeScan.java:1599)
        at 
org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndexMinion(DataDictionaryImpl.java:9288)
        at 
org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getDescriptorViaIndex(DataDictionaryImpl.java:9212)
        at 
org.apache.derby.impl.sql.catalog.DataDictionaryImpl.locateSchemaRow(DataDictionaryImpl.java:1722)
        at 
org.apache.derby.impl.sql.catalog.DataDictionaryImpl.getSchemaDescriptor(DataDictionaryImpl.java:1589)
        at 
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.initDefaultSchemaDescriptor(GenericLanguageConnectionContext.java:426)
        at 
org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext.initialize(GenericLanguageConnectionContext.java:401)
        at 
org.apache.derby.impl.db.BasicDatabase.setupConnection(BasicDatabase.java:295)
        at 
org.apache.derby.impl.jdbc.TransactionResourceImpl.startTransaction(TransactionResourceImpl.java:189)
        at 
org.apache.derby.impl.jdbc.EmbedConnection.<init>(EmbedConnection.java:441)
        at 
org.apache.derby.impl.jdbc.EmbedConnection30.<init>(EmbedConnection30.java:73)
        at 
org.apache.derby.impl.jdbc.EmbedConnection40.<init>(EmbedConnection40.java:51)
        at 
org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Driver40.java:70)
        at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:248)
        at 
org.apache.derby.jdbc.AutoloadedDriver.connect(AutoloadedDriver.java:146)
        at java.sql.DriverManager.getConnection(DriverManager.java:579)
        at java.sql.DriverManager.getConnection(DriverManager.java:190)
        at 
org.apache.derbyTesting.junit.DriverManagerConnector.openConnection(DriverManagerConnector.java:81)
        at 
org.apache.derbyTesting.junit.DriverManagerConnector.openConnection(DriverManagerConnector.java:43)
        at 
org.apache.derbyTesting.junit.TestConfiguration.openDefaultConnection(TestConfiguration.java:1574)
        at 
org.apache.derbyTesting.functionTests.tests.store.InterruptResilienceTest$WorkerThread.run(InterruptResilienceTest.java:432)
Exception in thread "WorkerThread. Thread#4" 
junit.framework.AssertionFailedError
        at junit.framework.Assert.fail(Assert.java:47)
        at junit.framework.Assert.assertTrue(Assert.java:20)
        at junit.framework.Assert.assertTrue(Assert.java:27)
        at 
org.apache.derbyTesting.functionTests.tests.store.InterruptResilienceTest$WorkerThread.run(InterruptResilienceTest.java:435)
........
Time: 175.745


> Thread's interrupted flag not always preserved after Derby returns from JDBC 
> API call
> -------------------------------------------------------------------------------------
>
>                 Key: DERBY-5223
>                 URL: https://issues.apache.org/jira/browse/DERBY-5223
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 10.8.1.2
>            Reporter: Dag H. Wanvik
>
> Sometimes we have this this stack trace on the log from SuitesAll:
> .Exception in thread "WorkerThread. Thread#5" 
> junit.framework.AssertionFailedError
>         at junit.framework.Assert.fail(Assert.java:47)
>         at junit.framework.Assert.assertTrue(Assert.java:20)
>         at junit.framework.Assert.assertTrue(Assert.java:27)
>         at 
> org.apache.derbyTesting.functionTests.tests.store.InterruptResilienceTest$WorkerThread.run(InterruptResilienceTest.java:430)
>  
> This happens sometimes when the application thread's interrupt flag is set 
> before we enter a Derby API call, but the flag is cleared on return contrary 
> to our specified behavior.
> Cf mention on 
> https://issues.apache.org/jira/browse/DERBY-5081?focusedCommentId=13030155&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13030155
> I can reproduce this every 20 runs or so on Linux with JDK7, but it has been 
> seen also on Windows, so it is not VM specific.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to