[
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-raf-stresstest-1.stat
derby-4741-raf-stresstest-1.diff
Uploading *-raf-stresstest-1, which adds a multi-threaded read/write test under
an interrupt shower.
This exercises primarily the random access file recovery
(RAFContainer4#recoverContainerAfterInterrupt), but since the interrupt can
arrive at any time during query execution, other parts of the code are also
exposed.
The new test case is InterruptResilienceTest#testRAFReadWriteMultipleThreads.
Running regressions.
The patch is not for commit yet, since I worry that the test takes too long to
be included in the regression suite. During development I had to let it run
this long to expose all the corner cases I have seen, but adding 250 seconds
may be too much. I could comment out the client/server suite, since it doesn't
add much value: the interrupt all happen on the server side. That would cut
the time down to ca half. Also, the test may not be entirely reliable yet,
since there are remaining parts of the code yet to vetted wrt interrupt
handling, but it runs reliably in my environment. I will at least run it on
some more platforms before I suggest any commit.
Please note that due to DERBY-4431, the IBM VMs will not yet be covered by
these additional tests.
> 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-b-02-nio.diff,
> derby-4741-b-02-nio.stat, derby-4741-b-03-nio.diff, derby-4741-b-03-nio.stat,
> derby-4741-b-04-nio.diff, derby-4741-b-04-nio.stat, derby-4741-c-01-nio.diff,
> derby-4741-c-01-nio.stat, derby-4741-kristians-01.diff,
> 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-4741-raf-stresstest-1.diff, derby-4741-raf-stresstest-1.stat,
> derby-4741-sleeps-waits-1.diff, derby-4741-sleeps-waits-1.stat,
> derby-4741-sleeps-waits-2.diff, derby-4741-sleeps-waits-2.stat,
> derby-4741-sleeps-waits-3.diff, derby-4741-sleeps-waits-3.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.
