db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
Date Fri, 08 Oct 2010 14:10:31 GMT

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

Dag H. Wanvik updated DERBY-4741:
---------------------------------

    Attachment: derby-4741-nio-container+log+waits.stat
                derby-4741-nio-container+log+waits.diff

Uploading a revised experimental patch, derby-4741-nio-container+log+waits, which intercepts
and saves away interrupts in 

- LogToFile#flush, when a thread is waiting for another thread to flush the log.
- BasePage#setExclusive (2 places)
- BasePage#setExclusiveNoWait

It also fixes a bug in NIO getEmbryonicPage; the new implementation tried to decrypt when
reading the embryonic page if the database were encrypted.

With these changes in place, the next issue that I sometime see is that we can get interrupted
waiting for a lock.

java.lang.InterruptedException
	at java.lang.Object.wait(Native Method)
	at org.apache.derby.impl.services.locks.ActiveLock.waitForGrant(ActiveLock.java:118)
	at org.apache.derby.impl.services.locks.ConcurrentLockSet.lockObject(ConcurrentLockSet.java:469)

In turn this led to continual failure because I hit this ASSERT:

at org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:147)
at org.apache.derby.impl.services.locks.LockControl.addLock(LockControl.java:276)

Knut suggested to me we try to treat this situation similarly to how we handle lock time-outs
and just throw an interrupted exception at safe place. Sounds good to me.

> 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-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, 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