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] [Issue Comment Edited] (DERBY-5243) assert failure in test testRAFReadWriteMultipleThreads: interrupted flag cleared
Date Tue, 24 May 2011 23:30:47 GMT

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

Dag H. Wanvik edited comment on DERBY-5243 at 5/24/11 11:30 PM:
----------------------------------------------------------------

[Edited: first analysis was slightly wrong]:

I did some tracing of this, and I suspect to be a bug in the JDK (1.4.2 and 5). In this case,
after we have seen an interrupt exception (08000) due seeing the thread interrupted in BasicNoPutResultSetImpl#checkCancellationFlag,
we want to reestablish the connection and reprepare the statement test, the flag should still
be set after the exception was received.

In the test code, the assert is made after we have performed those two operations (reopen,
prepare) have been performed, but by adding more trace I can see it already cleared when we
start handling the exception: It gets cleared while the thread is still inside EmbedConnection.movePosition's
call to handleException. 

While it is processing that (writing to derby.log among other things), I can see in my trace
that another thread gets interrupted and throws in the same way, which may or may not be relevant.
When i next see a trace from the first thread, its flag has been cleared. None of the threads
have been involved in NIO during this time inside handleException, although both could have
received yet another interrupt. But that shouldn't clear the flag, surely. The Thread#isInterrupted
method is a native method, which could explain why we see this only on Linux.


      was (Author: dagw):
    I did some tracing of this, and I suspect to be a bug in the JDK (1.4.2 and 5). In this
case, after we have seen an interrupt exception (08000) due to interrupted locking, we want
to reestablish the connection and reprepare the statement test, the flag still being set after
the exception was received. In the test code, the assert is made after we have performed those
two operations (reopen, prepare) have been performed, but in fact I can see it already cleared
when we start handling the exception. It gets cleared while the thread is still inside EmbedConnection.movePosition's
call to handleException. While it is processing that (writing to derby.log among other things),
I can see in my trace that another thread gets interrupted during NIO file channel IO. When
i next see a trace from the first thread, its flag has been cleared. The thread that loses
its interrupted flag has not, I believe, been involved in NIO during this time inside handleException,
although it could have received yet another interrupt. But that shouldn't clear the flag,
surely.

  
> assert failure in test testRAFReadWriteMultipleThreads: interrupted flag cleared
> --------------------------------------------------------------------------------
>
>                 Key: DERBY-5243
>                 URL: https://issues.apache.org/jira/browse/DERBY-5243
>             Project: Derby
>          Issue Type: Bug
>          Components: Test
>    Affects Versions: 10.8.1.2
>         Environment: Linux, Sun JDK 1.4.2u25 and JDK 5. Not seen or JDK 6 or 7, or other
OS than Linux
>            Reporter: Dag H. Wanvik
>            Priority: Minor
>         Attachments: DERBY-5243-instrument.diff, DERBY-5243-instrument.stat
>
>
> This is another instance of an interrupted thread losing its interrupted flag after calling
Derby, but I believe this is distinct from other we have seen.
> 1) testRAFReadWriteMultipleThreads(org.apache.derbyTesting.functionTests.tests.store.InterruptResilienceTest)java.sql.SQLException:
The exception 'junit.framework.AssertionFailedError: WorkerThread 0' was thrown while evaluating
an expression.
> 	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.seeNextException(Unknown Source)
> 	at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(Unknown Source)
> 	at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(Unknown Source)
> 	at org.apache.derby.impl.jdbc.EmbedConnection.handleException(Unknown Source)
> 	at org.apache.derby.impl.jdbc.ConnectionChild.handleException(Unknown Source)
> 	at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source)
> 	at org.apache.derby.impl.jdbc.EmbedStatement.execute(Unknown Source)
> 	at org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(Unknown Source)
> 	at org.apache.derbyTesting.functionTests.tests.store.InterruptResilienceTest.testRAFReadWriteMultipleThreads(InterruptResilienceTest.java:532)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	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)
> 	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)
> Caused by: java.sql.SQLException: Java exception: 'WorkerThread 0: junit.framework.AssertionFailedError'.
> 	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.TransactionResourceImpl.wrapInSQLException(Unknown Source)
> 	... 45 more
> Caused by: junit.framework.AssertionFailedError: WorkerThread 0
> 	at org.apache.derbyTesting.junit.BaseTestCase.fail(BaseTestCase.java:771)
> 	at org.apache.derbyTesting.functionTests.tests.store.InterruptResilienceTest.tstRAFReadWriteMultipleThreads(InterruptResilienceTest.java:323)
> 	at org.apache.derby.exe.ac070a00b0x0130x06edxad12x000062ebfce90.g0(Unknown Source)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at org.apache.derby.impl.services.reflect.ReflectMethod.invoke(Unknown Source)
> 	at org.apache.derby.impl.sql.execute.CallStatementResultSet.open(Unknown Source)
> 	at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown Source)
> 	at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source)
> 	... 41 more
> Caused by: junit.framework.AssertionFailedError
> 	at org.apache.derbyTesting.functionTests.tests.store.InterruptResilienceTest$WorkerThread.run(InterruptResilienceTest.java:430)

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

Mime
View raw message