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-5081) Various intermittent failures in InterruptResilienceTest
Date Thu, 17 Mar 2011 12:37:29 GMT

    [ 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:36 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) 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 munite 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 emantes 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.

  
> Various intermittent failures in InterruptResilienceTest
> --------------------------------------------------------
>
>                 Key: DERBY-5081
>                 URL: https://issues.apache.org/jira/browse/DERBY-5081
>             Project: Derby
>          Issue Type: Bug
>          Components: Test
>    Affects Versions: 10.8.0.0
>            Reporter: Knut Anders Hatlen
>         Attachments: derby.log
>
>
> A couple of failures have been seen in InterruptResilienceTest lately:
> 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)
> 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

Mime
View raw message