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