[
https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923367#action_12923367
]
Knut Anders Hatlen commented on DERBY-4741:
-------------------------------------------
I ran MicroAPITest with derby-4741-all+lenient+resurrect.diff (20 runs with
each configuration, insane jars, pageCacheSize=12500). Now I only see a 1%
degradation with the patch (p-value=0.07, according to the student t calculator
at http://www.bio.miami.edu/rob/Students_t.html), so that definitely looks like
a good improvement from the previous patch. I also modified the test so that it
reused existing test data instead of creating it on every run. Then I didn't
see any degradation. In fact, the results with the patch were 0.5% better than
trunk when I ran the test that way.
I also saw something similar with the previous patch. I saw an 8% degradation
with the unmodified test, but the degradation was only about 2% with the
modified test. This is also consistent with the findings Dag posted in the
comment dated 15/Oct/10 12:06 PM, where he saw that the full patch gave a 2.5%
degradation, whereas if he only applied the parts of the patch that were
actually exercised during the data collection phase of the test, he didn't see
any degradation.
I don't know why the changes in the test setup code alters the result this way.
The part of the test where we collect results should exercise the exact same
code path with the two variants of the test. This reminds me of the effects we
saw in DERBY-4233, which were attributed to JIT at that time. I think the
theory at that time was something like this: The just-in-time compiler collects
statistics before it compiles the code and uses the statistics to optimize the
generated native code. The more time we spend in the test setup code, the more
the statistics will be biased towards the setup code. For this test, that could
mean that the JIT-compiled native code is optimized for the insert code path,
whereas we're really only interested in the select code path in the test.
Furthermore, since the patch changes code on the insert code path, the
collected statistics and the chosen optimizations may change, and that may
ultimately affect how the select code is optimized, even if the select code
path barely has been touched by the patch.
> 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-all+lenient+resurrect.diff,
> derby-4741-all+lenient+resurrect.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, 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.
