[
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.stat
derby-4741-nio-container+log.diff
Uploading derby-4741-nio-container+log, which builds on the previous
experimental patch in the following ways:
- Adds logic to recover when switching the log file gets interrupted
(seen on Windows using Derby151Test). The retry had to precolate up
from the NIO code, so I use an internal exception (temporarily
borrow an exisiting one; should make a new one later)
- Makes RAFContainer4#getEmbryonicPage use a minion of readPage, so
getEmbryonicPage can take advantage of the recovery machinery as
well (it previously did a direct call to readFull, which made it
vulnerable to being interrupted; this was also seen on Windows.
Unfortunately, the latter could lead to deadlocks, because when
getEmbryonicPage is called from writeRAFHeader, the thread has a
lock on "this". If another thread is has been interrupted and is
about to do recovery, it would get stuck on waiting for the monitor
on "this", while the getEmbryonicPage reader would get stuck on
waiting on recovery to finish. To solve this, I had to let reads
from getEmbryonicPage throw an internal exception so it can back out
and release the monitor on "this" (in RAFContainer#clean), and do a
retry from that level.
The patch is just a snapshot of my experiments, only intended so
people could comment on the approach.
> 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.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
>
>
> 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.
