[
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
