db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
Date Thu, 21 Oct 2010 08:46:15 GMT

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

View raw message