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-5081) Intermittent failure in InterruptResilienceTest: IO thread times out waiting for another thread to recover channel
Date Wed, 04 May 2011 19:54:03 GMT

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

Dag H. Wanvik commented on DERBY-5081:
--------------------------------------

I have been able to reproduce this on Linux with JDK7. Instrumentation shows that this is
a JDK issue: The API guarantee is not beeing honored, cf. the following (instrumented to catch
the situation) code from RAFContainer4:

    private void writeFull(ByteBuffer srcBuffer,
                           FileChannel dstChannel,
                           long position)
            throws IOException
    {
        try {
            while(srcBuffer.remaining() > 0) {
                dstChannel.write(srcBuffer, position + srcBuffer.position());

                // (**) Sun JAVA NIO is weird: it can close the channel due to an
                // interrupt without throwing if bytes got transferred. Compensate,
                // so we can clean up. Bug 6979009,
                // http://bugs.sun.com/view_bug.do?bug_id=6979009
                if (Thread.currentThread().isInterrupted() &&
                        !dstChannel.isOpen()) {
                    throw new ClosedByInterruptException();
                }
            }
        } catch (ClosedByInterruptException e) {
            if (!Thread.currentThread().isInterrupted()) {

                // while (true) {
--->            //     try { Thread.sleep(200000); } catch (Exception ee) {}
                // }

                // Compensate for JDK 7 on Linux (b141):
                Thread.currentThread().interrupt();
            }
            throw e;
        }
    }

That is, when the thread is interrupted and the channel write throws
ClosedByInterruptException, the interrupt flag is not set, as per the
API, cf this sentence in the Javadoc for ClosedByInterruptException:


"Checked exception received by a thread when another thread interrupts
it while it is blocked in an I/O operation upon a channel. Before this
exception is thrown the channel will have been closed and the
interrupt status of the previously-blocked thread will have been set."

Note that in our test case, the thread's interrupt status is *before*
the FileChannel#write is attempted. I believe that the API contract
should still hold, though.

With this fix (setting the flag as shown above), I can't reproduces the issue in 100 runs,
where as without it I see it in every 5-10 runs or so.

> 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.1.2
>         Environment: Linux/JDK 7
> Java 7 (b135) on Debian 5.0
> OEL/JDK7
>            Reporter: Knut Anders Hatlen
>         Attachments: derby.log, 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)
> 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

Mime
View raw message