db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lily Wei (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
Date Wed, 10 Nov 2010 18:11:14 GMT

     [ 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.


Mime
View raw message