You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Dag H. Wanvik (JIRA)" <ji...@apache.org> on 2011/03/17 13:46:35 UTC
[jira] Issue Comment Edited: (DERBY-5081) Intermittent failure in
InterruptResilienceTest: IO thread times out waiting for another thread to
recover channel
[ https://issues.apache.org/jira/browse/DERBY-5081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007900#comment-13007900 ]
Dag H. Wanvik edited comment on DERBY-5081 at 3/17/11 12:45 PM:
----------------------------------------------------------------
Issue 1) Thanks for the upload of derby.log. Knut. A thread is waiting for recovery assumed to be performed by another thread, which never (at least within a minute never happens). I can tell why from the log. In any case, this behavior shuts down the database, and is thus no worse than the current Derby behavior. If we see this again with some frequency, I may try to instrument to code on trunk so we can get an insight to why this is sometimes happening.
Issue 2) [DERBY-5140] This part of the stack is interesting:
Caused by: java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at java.lang.Thread.join(Thread.java:1001)
at java.lang.Thread.join(Thread.java:1054)
at org.apache.derbyTesting.functionTests.tests.store.InterruptResilienceTest.tstRAFReadWriteMultipleThreads(InterruptResilienceTest.java:244)
at org.apache.derby.exe.ac070a00b0x012ex6c08x9759x00006a12110b0.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)
It shows that the thread driving the test sees an interrupt (in the
join waiting for the worked threads to terminate. Now, the interruptor
threads should only be interrupting the worker threads themselves, not
the driver test thread that started (and is now waiting for) the
worker threads. I am not sure how this join could get interrupted,
because the specification of Thread#join states that it will only
throw InterruptedException iff the thread doing the join (i.e. the
joinee) is interrupted.
Possible theories:
a) That somehow the exception is delivered to the wrong thread iff the
worker thread is in the final stages when it receives an interrupt
from the interruptor threads
b) The interrupts emanates from Derby shutdown, which his hard to see
could be happening here: we are still inside a test
(testRAFReadWriteMultipleThreads), in embedded mode.
Note that this run has already seen a failure in
AutomaticIndexStatisticsTest#testShutdownWhileScanningThenDelete prior
to hitting the error in InterruptResilienceTest. I don't have no
reason to suspect that the two are related at this point, though.
I'll split this bug in two.
was (Author: dagw):
Issue 1) Thanks for the upload of derby.log. Knut. A thread is waiting for recovery assumed to be performed by another thread, which never (at least within a minute never happens). I can tell why from the log. In any case, this behavior shuts down the database, and is thus no worse than the current Derby behavior. If we see this again with some frequency, I may try to instrument to code on trunk so we can get an insight to why this is sometimes happening.
Issue 2) This part of the stack is interesting:
Caused by: java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at java.lang.Thread.join(Thread.java:1001)
at java.lang.Thread.join(Thread.java:1054)
at org.apache.derbyTesting.functionTests.tests.store.InterruptResilienceTest.tstRAFReadWriteMultipleThreads(InterruptResilienceTest.java:244)
at org.apache.derby.exe.ac070a00b0x012ex6c08x9759x00006a12110b0.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)
It shows that the thread driving the test sees an interrupt (in the
join waiting for the worked threads to terminate. Now, the interruptor
threads should only be interrupting the worker threads themselves, not
the driver test thread that started (and is now waiting for) the
worker threads. I am not sure how this join could get interrupted,
because the specification of Thread#join states that it will only
throw InterruptedException iff the thread doing the join (i.e. the
joinee) is interrupted.
Possible theories:
a) That somehow the exception is delivered to the wrong thread iff the
worker thread is in the final stages when it receives an interrupt
from the interruptor threads
b) The interrupts emanates from Derby shutdown, which his hard to see
could be happening here: we are still inside a test
(testRAFReadWriteMultipleThreads), in embedded mode.
Note that this run has already seen a failure in
AutomaticIndexStatisticsTest#testShutdownWhileScanningThenDelete prior
to hitting the error in InterruptResilienceTest. I don't have no
reason to suspect that the two are related at this point, though.
I'll split this bug in two.
> Intermittent failure in InterruptResilienceTest: IO thread times out waiting for another thread to recover channel
> ------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-5081
> URL: https://issues.apache.org/jira/browse/DERBY-5081
> Project: Derby
> Issue Type: Bug
> Components: Store, Test
> Affects Versions: 10.8.0.0
> Reporter: Knut Anders Hatlen
> Attachments: derby.log
>
>
> A couple of failures have been seen in InterruptResilienceTest lately: (Edit: Dag. this issue is for the first one only, the second issue has been allocated DERBY-5140)
> Linux/JDK 7 - http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.7/testing/testlog/lin/1075421-suitesAll_diff.txt :
> testRAFWriteInterrupted(org.apache.derbyTesting.functionTests.tests.store.InterruptResilienceTest)java.sql.SQLException: DERBY SQL error: SQLCODE: -1, SQLSTATE: 38000, SQLERRMC: java.sql.SQLException: Derby thread received an interrupt during a disk I/O operation, please check your application for the source of the interrupt.38000XSDG9:XSDG9.D
> at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown Source)
> at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source)
> at org.apache.derby.client.am.Statement.executeUpdate(Unknown Source)
> at org.apache.derbyTesting.functionTests.tests.store.InterruptResilienceTest.testRAFWriteInterrupted(InterruptResilienceTest.java:204)
> [edit: treatment of this is moved to DERBY-5140: Windows 2003/Java 1.4.2 - http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.4/testing/testlog/w2003/1075087-suitesAll_diff.txt:
>
> testRAFReadWriteMultipleThreads(org.apache.derbyTesting.functionTests.tests.store.InterruptResilienceTest)java.sql.SQLException: The exception 'java.lang.InterruptedException' 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:515)
> ]
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira