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

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

Thanks, Lily, for looking at the latest patch. I agree the code is a bit 
tricky, so there could be bugs.  Feel free to ask detailed questions, I'll try 
to answer.

 I did not see any issue with testPartialRowRTStats when I ran the regressions, 
nor would I expect this patch for increase perm gen space since it doesn't add 
new classes. But we have seen that perm gen space can be an issue when running 
regressions. I think I recently upped my pergen space setting for suitesAll to 
192m. I have also seen failures in the replication tests, there are some 
instabilities left, but I don't think they are due to this patch. 

You are right that the current test, InterruptResilienceTest, is pretty thin 
right now, but it does exercise the RAF recovery machinery with two concurrent 
threads (user thread and the raw store daemon).  

I intend to make more tests; the trick is to make sure the tests actually 
exercise the code paths we want: just shooting interrupts at threads can land 
anywhere during execution, and Derby doesn't stand up to it in all places yet. 
I plan to use the SanityManager + a debug flag to simulate interrupt at 
selected places in the code. If  you have suggestions for good tests, please 
let's have them :) 

> Make Derby work reliably in the presence of thread interrupts
> -------------------------------------------------------------
>
>                 Key: DERBY-4741
>                 URL: https://issues.apache.org/jira/browse/DERBY-4741
>             Project: Derby
>          Issue Type: Bug
>          Components: Store
>    Affects Versions: 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1, 10.3.3.0, 
> 10.4.1.3, 10.4.2.0, 10.5.1.1, 10.5.2.0, 10.5.3.0, 10.6.1.0
>            Reporter: Dag H. Wanvik
>            Assignee: Dag H. Wanvik
>         Attachments: derby-4741-a-01-api-interruptstatus.diff, 
> derby-4741-a-01-api-interruptstatus.stat, 
> derby-4741-a-02-api-interruptstatus.diff, 
> derby-4741-a-02-api-interruptstatus.stat, 
> derby-4741-a-03-api-interruptstatus.diff, 
> derby-4741-a-03-api-interruptstatus.stat, 
> derby-4741-a-04-api-interruptstatus.diff, 
> derby-4741-a-04-api-interruptstatus.stat, 
> derby-4741-all+lenient+resurrect.diff, derby-4741-all+lenient+resurrect.stat, 
> derby-4741-b-01-nio.diff, derby-4741-b-01-nio.stat, 
> derby-4741-nio-container+log+waits+locks+throws.diff, 
> derby-4741-nio-container+log+waits+locks+throws.stat, 
> derby-4741-nio-container+log+waits+locks-2.diff, 
> derby-4741-nio-container+log+waits+locks-2.stat, 
> derby-4741-nio-container+log+waits+locks.diff, 
> derby-4741-nio-container+log+waits+locks.stat, 
> derby-4741-nio-container+log+waits.diff, 
> derby-4741-nio-container+log+waits.stat, derby-4741-nio-container+log.diff, 
> derby-4741-nio-container+log.stat, derby-4741-nio-container-2.diff, 
> derby-4741-nio-container-2.log, derby-4741-nio-container-2.stat, 
> derby-4741-nio-container-2b.diff, derby-4741-nio-container-2b.stat, 
> derby.log, derby.log, InterruptResilienceTest.java, MicroAPITest.java, 
> xsbt0.log.gz
>
>
> When not executing on a small device VM, Derby has been using the Java NIO 
> classes java.nio.clannel.* for file io.
> If thread is interrupted while executing blocking IO operations in NIO, the 
> ClosedByInterruptException will get thrown. Unfortunately, Derby isn't 
> current architected to retry and complete such operations (before passing on 
> the interrupt), so the Derby database can be left in an inconsistent state 
> and we therefore have to return a database level error. This means the 
> applications can no longer access the database without a shutdown and reboot 
> including a recovery.
> It would be nice if Derby could somehow detect and finish IO operations 
> underway when thread interrupts happen before passing the exception on to the 
> application. Derby embedded is sometimes embedded in applications that use 
> Thread.interrupt to stop threads.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to