[ 
https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Lily Wei updated DERBY-4741:
----------------------------

    Attachment: InterruptResilienceTest.java

Hi Dag: Thank you so much for the continue effort to fix this issue. It will 
benefit a lot of customers and this is truly a hard bug/feature to fix. I am 
still trying to process the effect of FileContainer/RAFContainer/RAFContainer4. 
I don't quite understand it yet. The performance result for MicroAPITest is 
5s-7s for insane build and 45s-47s for sane build. That's great. Regression can 
have failure on my windows environment: testPartialRowRTStats(Java exception: 
'PermGen space: java.lang.OutOfMemoryError) or
 testReplicationt_Local_1_Indexing(java.sql.SQLException: DERBY SQL
 error: SQLCODE: -1, SQLSTATE: XJ041, SQLERRMC: Failed to create database 'c:\de
rby5\trunk\testall\db_master\wombat', see the next exception for details.::SQLST
ATE: XBM0JDirectory c:\derby5\trunk\testall\db_master\C:\derby5\trunk\testall\db
_master\wombat already exists. I run Suites.all three times, they all have 
similar failures. I can not reproduce if I run the test individually. Will this 
patch affect memory consumption? Will the timing change on cf cause 
java.sql.SQLException: DERBY SQL error: SQLCODE: -1, SQLSTATE: XJ041, SQLERRMC? 
I am not 100% sure. Or, they were just existing issues. For more multi thread 
purpose, I add to InterrupResilienceTest suite. If it is in the right 
direction, I can keep explore to make more other positive interrupt cases. 
Thanks Krisitan for the AbstractMTThread class.  I am so happy to work on this. 
Yeah!!!


> 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