[
https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12923457#action_12923457
]
Lily Wei commented on DERBY-4741:
---------------------------------
I can confirm Knut's number for MicroAPITest .java in turn of 1-3% degradation
or some case better with the derby-4741-all+lenient+resurrect.diff patch.
Thanks for all the great work, Dag. A lot of customers will benefit from this.
Wow!!!
It seems like we will throw an error back to the caller indicate they are the
one generating the interrupt and we will throw an error in the case of an
interrupt during a lock wait with this new approach. Will you elaborate on that
in turn of the new patch behavior please? I am still having trouble understand
the data flow perspective and would like to see some write out in turn of what
exact error I will see from Derby .
This is one of the comments you wrote to me. Sorry for getting back to you
promptly.
>> Do we need InterruptException on synchronized (slaveRecoveryMonitor) in
>> LogToFile.recover(...)?
>I don't think I changed that part of the code. I see that an interrupt
>is just ignored there, so I think we can safely add a call to
>"InterruptStatus.setInterrupted" there as well, if that's what you
>mean.
Yes, this is what I mean. And, I add it to my client space and run some tests.
It seems not harming anything. I know you are concentrating on "normal
operation" and it is *really* a lot of work. Will we add a note somewhere about
the code not cover for this interrupt handling? Such as: backup,
export/import, LOB/CLOB streams and replication for during I/O in those areas
as well.
I run Suites.all on windows and it is looking better than ever!!!
> 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.
