db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5223) Thread's interrupted flag not always preserved after Derby returns from JDBC API call
Date Mon, 09 May 2011 16:49:03 GMT

    [ 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

Mime
View raw message