db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5223) Thread's interrupted flag not always preserved after Derby returns from JDBC API call
Date Tue, 10 May 2011 13:34:47 GMT

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

Knut Anders Hatlen commented on DERBY-5223:
-------------------------------------------

That's a good catch! :) The fix looks fine to me. Resetting the flag in resetFromPool() sounds
like a good precaution, but just to verify that I haven't misunderstood: If the flag is non-null
when resetFromPool() is called, the (physical) connection has been interrupted and closed,
so it's not likely that it's possible to reuse it? In any case, resetting it sounds like the
right thing to do.

As to the changes in InterruptResilienceTest, would it be better to make WorkerThread preserve
all Throwables? It sounds useful to be allowed to use asserts there, and I could easily imagine
that someone later adds an assert call there without realizing that it won't be detected.
Just to prove my point: There's still an assertEquals() call left in WorkerThread after the
patch... ;)

> Thread's interrupted flag not always preserved after Derby returns from JDBC API call
> -------------------------------------------------------------------------------------
>
>                 Key: DERBY-5223
>                 URL: https://issues.apache.org/jira/browse/DERBY-5223
>             Project: Derby
>          Issue Type: Bug
>          Components: JDBC
>    Affects Versions: 10.8.1.2
>            Reporter: Dag H. Wanvik
>         Attachments: derby-5223.diff, derby-5223.stat
>
>
> Sometimes we have this this stack trace on the log from SuitesAll:
> .Exception in thread "WorkerThread. Thread#5" junit.framework.AssertionFailedError
>         at junit.framework.Assert.fail(Assert.java:47)
>         at junit.framework.Assert.assertTrue(Assert.java:20)
>         at junit.framework.Assert.assertTrue(Assert.java:27)
>         at org.apache.derbyTesting.functionTests.tests.store.InterruptResilienceTest$WorkerThread.run(InterruptResilienceTest.java:430)

> This happens sometimes when the application thread's interrupt flag is set before we
enter a Derby API call, but the flag is cleared on return contrary to our specified behavior.
> Cf mention on https://issues.apache.org/jira/browse/DERBY-5081?focusedCommentId=13030155&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13030155
> I can reproduce this every 20 runs or so on Linux with JDK7, but it has been seen also
on Windows, so it is not VM specific.

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

Mime
View raw message