Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Tue, 10 May 2011 13:34:47 +0000 (UTC)
From: "Knut Anders Hatlen (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <729117183.151.1305034487426.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <689387383.32690.1304958363160.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (DERBY-5223) Thread's interrupted flag not
 always preserved after Derby returns from JDBC API call
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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