db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4741) Make embedded Derby work reliably in the presence of thread interrupts
Date Sat, 26 Feb 2011 03:09:22 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12999701#comment-12999701
] 

Dag H. Wanvik commented on DERBY-4741:
--------------------------------------

Hi Lily, it is not clear to me either ;-) The dependencies in our
present compile is partly hard coded in the build.xml files, but that
is not the whole story. It seems that if the compiler notices it lacks
a class, it can check for it in the source path and compile it outside
the normal order to fulfill the dependency. Setting the classpath to
"" denies the compiler task this ability, forcing the hard coded
dependencies to be the unique determinants of compilation order. Knut
did an experiment to do that for most compiles, but it quickly turned
messy as far as I understood.

Cf this quote from the javac task doc (http://www.jajakarta.org/ant/ant-1.6.1/docs/en/manual/CoreTasks/javac.html):

"If you wish to compile only files explicitly specified and disable
javac's default searching mechanism then you can unset the sourcepath
attribute:

  <javac sourcepath="" srcdir="${src}"
         destdir="${build}" >
    <include name="**/*.java" />
    <exclude name="**/Example.java" />
  </javac>

That way the javac will compile all java source files under "${src}"
directory but skip the examples. The compiler will even produce errors
if some of the non-example files refers to them. "

So far so good. I can't explain why setting jsr169compile.classpath
explicitly made things break though. I just fiddled with the placement
of the compilation of mbeans till it worked... :( But in general, it
matters under which javac tash a class is compiled in Derby, since we
use so many tweaks for classpath handling to enable seperate Java
versions, jsr169, JDBC3, 4... I think it woul dbe good if we could
move to having the dependencies better understood and encoded in the
build files, cf. Knut's experiment, so we can untangle all these
intricate dependencies, and suffer less every time anything changes..


> Make embedded 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
>              Labels: derby_triage10_8
>         Attachments: InterruptResilienceTest.java, MicroAPITest.java, 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-fix-compilation.diff, derby-4741-fix-compilation.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-raf-stresstest-2.diff,
derby-4741-raf-stresstest-2.stat, derby-4741-raf-stresstest-3.diff, derby-4741-raf-stresstest-3.stat,
derby-4741-raf-stresstest-4.diff, derby-4741-raf-stresstest-4.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-4741-sleeps-waits-more.diff,
derby-4741-sleeps-waits-more.stat, derby-4741-testBatchInterrupt-b.diff, derby-4741-testBatchInterrupt.diff,
derby-4741-testQueryInterrupt.diff, derby-4741-testQueryInterrupt.stat, derby.log, derby.log,
interrupts-fs.html, interrupts-fs.html, interrupts-fs.html, interrupts-fs.html, sleep-1-usages.txt,
wait-0-usages.txt, wait-1-usages.txt, 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 for extra concurrency.
> If a 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 store can be left in an
inconsistent state, although no data is corrupted, and we therefore have to return a database
level error to perform shutdown and recovery. This means the applications can no longer access
the database while a shutdown and reboot including a recovery is taking place.
> 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.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

       

Mime
View raw message