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] Issue Comment Edited: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
Date Wed, 08 Dec 2010 22:26:02 GMT

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

Dag H. Wanvik edited comment on DERBY-4741 at 12/8/10 5:25 PM:
---------------------------------------------------------------

While I am looking for the Heisenbug in DERBY-4920, I am considering the next increment of
this patch from the
prototype patch regarding the issues seen when interrupt hits the logging machinery (mostly
not NIO, except for the case of DirRandomAccessFile#sync).
Now, it turns out that the vulnerability here only applies for Solaris. Other platforms' "non-NIO"
IO is not interruptible, so for those other platforms there is no need to do anything special.
For Solaris, the behavior can be tweaked to be impervious to interrupts as well using the
special switch: -XX:-UseVMInterruptibleIO on JVMs >= 1.5.0_12. This behavior will be default
in 1.7 also on Solaris[1].
So the question becomes, would it be sufficient to advise users to run with this switch set,
or should we make Derby tolerate
the interrupts on Solaris here also? 

I do think we should be able to run correctly with the default settings on all relevant platforms,
but I would appricate your opinions.

[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4385444

      was (Author: dagw):
    While I am looking for the Heisenbug in DERBY-4920, I am considering the next increment
of this patch from the
prototype patch regarding the issues seen when interrupt hits the logging machinery (mostly
not NIO, except for the case of DirRandomAccessFile#sync).
Now, it turns out that the vulnerability here only applies for Solaris. Other platforms' "non-NIO"
IO is not interruptible, so for those other platforms there is no need to do anything special.
For Solaris, the behavior can be tweaked to be impervious to interrupts as well using the
special switch: -XX:-UseVMInterruptibleIO on JVMs >= 1.5.0_12. This behavior which will
be default in 1.7 also on Solaris[1].
So the question becomes, would it be sufficient to advise users to run with this switch set,
or should we make Derby tolerate
the interrupts on Solaris here also? 

I do think we should be able to run correctly with the default settings on all relevant platforms,
but I would appricate your opinions.

[1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4385444
  
> 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.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.


Mime
View raw message