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 Derby work reliably in the presence of thread interrupts
Date Fri, 08 Oct 2010 20:58:31 GMT

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

Dag H. Wanvik commented on DERBY-4741:

Hi Mike, thanks for looking at this!

> I was wondering if you have a high level
> goal. Basically what should derby do when it encounters an
> interrupt.

I started off merely trying to make the new IO pieces stand up as well
as the old I/O, but I guess my ambitions grew a bit as I found many
things could bring Derby down..

My thinking so far is that Derby should:

a) avoid having to shut down if a thread has been interrupted

b) throw *something* when it finds the thread has been interrupted,
preferably as soon as possible, but not before the code has arrived at
a "safe place", so we can avoid Derby shutting down.

> I think it should always throw some sort of error back to caller,
> and would be nice if the error or the nested error indicated clearly
> that it is being thrown because of a thread interrupt. Many times
> when supporting this issue it takes awhile for the user to realize
> that they are the ones generating the interrupt.

Agreed. So far I have been thinking of just using the connection level error 08000,
wrapping the original NIO channel exception, or InterruptedException.
This should make it clear what has happened, and unwrapping the exception would 
show where Derby detected it.

> I think the error should not be database level, and with your retry
> on I/O and log it seems like we can avoid that. 

That's what I am trying to achieve, yes.

> I am not sure if it should be session or statement level, I am
> leaning to it being session level, but would like to see a
> discussion. I know often users are doing the interrupt to stop a
> thread.

The existing code throws session level error 08000 already in many
places, and I felt it's OK to require that the user reconnect when she
has done something as drastic as interrupting the thread (?)

> Ultimately do you plan on always reenabling the interrupt after
> retrying or getting to a safe place?

I am still pondering this question. I *think* that by the principle of
least surprise to the user, we should set the interrupted flag of the
thread again just before we throw the exception from the "safe place".

Note: the exisiting code does not resurrect the
thread's interrupted flag when it detects an interrupt of a wait and throws
StandardException.interrupt. (wait would have cleared the flag). 

An imminent problem is where would the "safe place" be? It would be
nice to *avoid* having to check in all JDBC API methods before we
return if Derby has been interrupted during the API call, but I am not
yet sure if I am able to determine conclusively which API code paths
could lead to Derby being interrupted.. One approach would be to throw
as "soon as possible" from a "safe place" on the stack above the
method that saw the interrupt, but it may be hard to always determine
where that would be in all cases. I am open to suggestions here :)

The current experimental patch mostly doesn't throw yet (I didn't get
that far) - it just makes a note that an interrupt was detected. Nor
does it resurrect the interrupted flag when it does throw - since I
was still torn on this.

> We should definitely throw an error in the case of an interrupt
> during a lock wait, this seems like the one valid case to send an
> interrupt to derby if a user thinks it is waiting too
> long. Hopefully you can code it to handle it, do processing, get to
> safe spot and then throw an error indicating a real user interrupt
> during a wait.

Yes, I am trying to do exactly that, agreed. 

I also would like interrupts on queries to be detected no later that
at the place where we check for query time-outs already,
cf. BasicNoPutResultSetImpl#checkCancellationFlag.

> Something to think about in the error throwing is the background
> thread. What should we do if it encounters an interrupt. Throwing an
> error there might shutdown the db, i am not sure what it does at top
> level with an error.

Right. A priori, I thought the most common use case would be user
threads getting interrupted, but I'll look into that. One approach
could be to shutdown, or possibly try to make it impervious and ignore
all interrupts..

> 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-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, 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