[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Attachment: interrupts-fs.html Uploading a new version of the draft functional specification, version 0.2. Please have a look! > 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: 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-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-testQueryInterrupt.diff, derby-4741-testQueryInterrupt.stat, > derby.log, derby.log, interrupts-fs.html, interrupts-fs.html, 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. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Issue & fix info: [Patch Available] > 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: 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-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-testQueryInterrupt.diff, derby-4741-testQueryInterrupt.stat, > derby.log, derby.log, interrupts-fs.html, 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. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Attachment: derby-4741-testQueryInterrupt.stat derby-4741-testQueryInterrupt.diff Uploading a patch, *-testQueryInterrupt, which: * adds a new test case: InterruptResilienceTest#testLongQueryInterrupt which tests that a query will check for the interrupt flag and throw 08000 (CONN_INTERRUPT) at the same time is checks for query time-out. * adds a missing test in InterruptStatus#throwIf I also adjusted an existing test (for RAF recovery) to handle the case that we could see 08000 (CONN_INTERRUPT) when performing a query as part of that test, depending on when the interrupt happens. Regressions passed. > 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: 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-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-testQueryInterrupt.diff, derby-4741-testQueryInterrupt.stat, > derby.log, derby.log, interrupts-fs.html, 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. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Attachment: interrupts-fs.html Uploading a functional specification for this work to summarize what we have so far: "interrupts-fs.html" > 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-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.log, > derby.log, InterruptResilienceTest.java, interrupts-fs.html, > 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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Attachment: derby-4741-raf-stresstest-4.stat derby-4741-raf-stresstest-4.diff Uploading version #4 (derby-4741-raf-stresstest-4). This lets the test run with its own database since we use durability=test: just to be on the safe side, so other tests don't get impacted by the fact that the database is thus marked, cf. message in derby.log: "WARNING: The database is booted with derby.system.durability=test. In this mode, it is possible that database may not be able to recover, committed transactions may be lost, database may be in an inconsistent state. Please use this mode only when these consequences are acceptable" (sic: no final period) I has to add a class.forName to DriverManagerConnector#getConnectionByAttributes and a new public method BasicJDBCTestCase#openDefaultConnection(TestConfiguration). The latter makes it possible use the main thread's test configuration in the server threads, cf. "thisConfig" member in InterruptResilienceTest. I also added derby.infolog.append=true to SystemPropertyTestSetup, so the c/s run doesn't clobber the embedded run's derby.log. Rerunning regressions. > 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-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.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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Attachment: derby-4741-raf-stresstest-3.stat derby-4741-raf-stresstest-3.diff Uploading a revised version #3 which makes use of derby.system.durability=testing to cut down on the running time on Solaris, I found it will still get to the corner cases. > 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-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-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.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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Attachment: derby-4741-raf-stresstest-2.stat derby-4741-raf-stresstest-2.diff Uploaded *raf_stresstest-2 which supersedes #1. In addition to fixing Knut's nits, the server side code now uses a thread's default test configuration directly, and I also added a comment explaining this. I think I will commit the patch with the long running time for now. I'd rather flush out any bugs here sooner rather than later. > 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-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-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.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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Attachment: derby-4741-raf-stresstest-1.stat derby-4741-raf-stresstest-1.diff Uploading *-raf-stresstest-1, which adds a multi-threaded read/write test under an interrupt shower. This exercises primarily the random access file recovery (RAFContainer4#recoverContainerAfterInterrupt), but since the interrupt can arrive at any time during query execution, other parts of the code are also exposed. The new test case is InterruptResilienceTest#testRAFReadWriteMultipleThreads. Running regressions. The patch is not for commit yet, since I worry that the test takes too long to be included in the regression suite. During development I had to let it run this long to expose all the corner cases I have seen, but adding 250 seconds may be too much. I could comment out the client/server suite, since it doesn't add much value: the interrupt all happen on the server side. That would cut the time down to ca half. Also, the test may not be entirely reliable yet, since there are remaining parts of the code yet to vetted wrt interrupt handling, but it runs reliably in my environment. I will at least run it on some more platforms before I suggest any commit. Please note that due to DERBY-4431, the IBM VMs will not yet be covered by these additional tests. > 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-4741-raf-stresstest-1.diff, derby-4741-raf-stresstest-1.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.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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Issue & fix info: (was: [Patch Available]) > 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-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.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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Attachment: derby-4741-sleeps-waits-3.stat derby-4741-sleeps-waits-3.diff Uploading rev #3 of sleeps-waits, rerunning regressions. > 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-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.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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Attachment: derby-4741-sleeps-waits-2.stat derby-4741-sleeps-waits-2.diff Uploading a second version of derby-4741-sleeps-waits, rerunning regressions. Details on where patch derby-4741-sleeps-waits-2 adds things relative to version 1: The following locations previously silently swallowed the interrupt, we now (also) note that an interrupt occurred: * LogAccessFile: #flushDirtyBuffers: - While waiting for another thread flushing #syncLogAccessFile: - While sleeping a bit before retrying after a failed sync With the above, all the waits and sleeps in the package org.apache.derby.impl.store.raw.log have been made safe. The following locations where we earlier threw 08000 (CONN_INTERRUPT), we now just note that an interrupt occurred: * XactFactory: #blockBackup: - While doing backup blocking operations, we wait for backup to finish. #blockBackupBlockingOperations: - While waiting for all backup blocking operations to complete * BaseDataFileFactory: #freezePersistentStore: - While waiting for writes in progress to finishing before freezing. #writeInProgress: - While waiting for db thaw before we can start writing * CachedPage: #clean: - Waiting for another thread cleaning it - Waiting for state to become unlatched attempting to clean it * AsynchronousLogShipper: #run: - If interrupted during the shipping interval wait, shipping sooner doesn't hurt #forceFlush: - While waiting a bit after having flushed the master to ship log records to slave to free up buffer space * ReplicationMessageReceive: #isConnectedToMaster: - While waiting for result from the ping thread (the "pong"). Since we may have been interrupted before the result is ready, we try again unless the connection is confirmed up. #SlavePingThread#run: - While waiting for wakeup to do a ping. I had to introduce an extra state variable here to decide whether after we receive an interrupt, a ping request has also been lodged. > 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-4741-sleeps-waits-1.diff, derby-4741-sleeps-waits-1.stat, > derby-4741-sleeps-waits-2.diff, derby-4741-sleeps-waits-2.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 recov
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Issue & fix info: [Patch Available] > 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-4741-sleeps-waits-1.diff, derby-4741-sleeps-waits-1.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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Attachment: derby-4741-sleeps-waits-1.stat derby-4741-sleeps-waits-1.diff Uploading a patch derby-4741-sleeps-waits-1 which adds handling of some cases of interrupted monitor wait calls and Thread.sleep calls which I found needed changes to make my preliminary tests work. Running regressions. There are remaining places (i.e. usages for wait & sleep) in the code base which need to be inspected for modification. I will be making one or more follow-up patches to handle those. With the current patch this work is approaching a state where Derby embedded(*) is sufficiently robust against interrupts that I will move to buillding systematic as well as randomized tests, and plug remaining holes as we find them. (*) the server code needs consideration too, as well as the client code. > 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-4741-sleeps-waits-1.diff, derby-4741-sleeps-waits-1.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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Matrigali updated DERBY-4741: -- I agree with the tradeoff you suggest concerning syncing the log file. It seems to make the code easier and will not really affect most users running on modern platforms while still allowing those few to still work correctly on back releases. This especially seems to make sense as I don't see us backporting this change so should only affect 10.8. > 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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Attachment: derby-4741-kristians-01.diff Uploading derby-4741-kristians-01, running regressions. > 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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Issue & fix info: (was: [Patch Available]) > 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-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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Issue & fix info: [Patch Available] > 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-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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Attachment: derby-4741-c-01-nio.stat derby-4741-c-01-nio.diff This patch (derby-4741-c-01-nio) closes two race conditions I have observed when stress testing the RAFContainer4 recovery mechanism. It does some other small cleanups. Regressions ran OK. RAFContainer: If we receive an interrupt when the container is first being opened (i.e. during RAFContainer.run (OPEN_CONTAINER_ACTION) -> getEmbryonicPage), recovery will fail because currentIdentity needed in RAFContainer4#recoverContainerAfterInterrupt hasn't yet been set. RAFContainer4: If a stealthMode read is interrupted and is recovering the container, it erroneously increments threadsInPageIO just before exiting to retry IO. This leads to a break in the invariant that threadsInPageIO be 0 when all threads are done, causing issue (hang) down the line. If, when we are reopening the container, the read being done during that operation (getEmbryonicPage), that stealth mode read will also lead to a (recursive) recovery. We have to catch this case by adding a "catch (InterruptDetectedException e)" just after the call to openContainer, not by testing the interrupt flag as presently done, since the recovery inside the recursive call to getEmbryonicPage/readPage will already have cleared the flag and done recovery. When giving up reopening the container for some reason, we also forgot to decrement threadsInPageIO. To guard against other hangs, I will make the while-true loops max out in all cases. But before I commit that change, it would be nice to see if this patch has any impact on DERBY-4920 (I suspect not). The reason I'd like to hold off with that is that since DERBY-4920 occurs during shutdown, that may mask the fact that recovery failed, cf. my comment https://issues.apache.org/jira/browse/DERBY-4920?focusedCommentId=12936016&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12936016 So, I'd rather wait with that till I get DERBY-4920 out of the way. > 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-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
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Issue & fix info: (was: [Patch Available]) > 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-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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Attachment: derby-4741-b-04-nio.stat derby-4741-b-04-nio.diff Uploading b-04, which cleans up and adds some more debug tracing to RAFContainer4. > 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-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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Attachment: derby-4741-b-03-nio.stat derby-4741-b-03-nio.diff Uploading patch b-03 which adds logic to RAFContainer4 to handle properly the fact that a container can't be reopened: // In case the recovering thread can't successfully recover the container, // it will throw, so other waiting threads need to give up as well. This // can happen at shutdown time when interrupts are used to stop threads. private boolean giveUpIO = false; private final Object giveUpIOm = new Object(); // its monitor We make sure to notify any waiting threads when the recovering thread throw. The waiting threads will next see giveUpIO == true, and give up as well. This should make sure that threads not doing the recovery, will detect that recovery will not happen, and throw as well. SuitesAll finished successfully. > 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-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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Issue & fix info: [Patch Available] > 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-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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Attachment: derby-4741-b-02-nio.stat derby-4741-b-02-nio.diff > 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-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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lily Wei updated DERBY-4741: Attachment: InterruptResilienceTest.java Hi Dag: Thank you so much for the continue effort to fix this issue. It will benefit a lot of customers and this is truly a hard bug/feature to fix. I am still trying to process the effect of FileContainer/RAFContainer/RAFContainer4. I don't quite understand it yet. The performance result for MicroAPITest is 5s-7s for insane build and 45s-47s for sane build. That's great. Regression can have failure on my windows environment: testPartialRowRTStats(Java exception: 'PermGen space: java.lang.OutOfMemoryError) or testReplicationt_Local_1_Indexing(java.sql.SQLException: DERBY SQL error: SQLCODE: -1, SQLSTATE: XJ041, SQLERRMC: Failed to create database 'c:\de rby5\trunk\testall\db_master\wombat', see the next exception for details.::SQLST ATE: XBM0JDirectory c:\derby5\trunk\testall\db_master\C:\derby5\trunk\testall\db _master\wombat already exists. I run Suites.all three times, they all have similar failures. I can not reproduce if I run the test individually. Will this patch affect memory consumption? Will the timing change on cf cause java.sql.SQLException: DERBY SQL error: SQLCODE: -1, SQLSTATE: XJ041, SQLERRMC? I am not 100% sure. Or, they were just existing issues. For more multi thread purpose, I add to InterrupResilienceTest suite. If it is in the right direction, I can keep explore to make more other positive interrupt cases. Thanks Krisitan for the AbstractMTThread class. I am so happy to work on this. Yeah!!! > 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-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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Attachment: derby-4741-b-01-nio.stat derby-4741-b-01-nio.diff Uploading patch derby-4741-b-01-nio. This patch contains changes to FileContainer/RAFContainer/RAFContainer4 to allow page IO to recover from interrupts seen in RAFContainer4 (the NIO[1] version specialization of RAFContainer). Additionally, some waits are changed to retry after interrupts (yes, there are more of those in other classes, that's for a later patch, but since I was in there anyway..) The main thrust of the patch is in RAFContainer4. Upon seeing exceptions from IO (readPage/writePage), a thread will determine if it is a) the thread that caused the channel to beclome closed, or b) it suffered an exceptions because another thread caused the channel to beclome closed. If a), the thread will recover by reopening the container before reattempting IO, cf. the method recoverContainerAfterInterrupt. If b) the thread will yield, wait and retry until the container has been recovered, or a minute has passed. After a minute, we give up and throw FILE_IO_INTERRUPTED. I chose a minute somewhat arbitrarily, it is hopefully sufficient (?). The recovery thread and other waiting threads normally synchronize the operations via variables protected by the channelCleanupMonitor monitor (but see use of volatile and associated comments). The retry logic happens in one of three places, in increasing closeness to RAFContainer4: a) if the thread owns the monitor on allocCache and it is not the one that is doing recovery, it will back up to FileContainer before retrying the IO, since it has to release the lock on allocCache, because that monitor is needed by the thread doing recovery. Cf. changes in FileContainer. If the thread holds allocCache, it goes into stealth mode in readPage/WritePage: this means that the recovery thread doesn't see it. We can't let a stealth mode thread grab channelCleanupMonitor, as this could cause a dead-lock. In c) the recovery thread keeps track of other threads, waking them up when recovery is done. b) if the thread owns the monitor on "this", again the thread goes into stealth mode. If it is not the one to clean up, it will back up to RAFContainer#clean's loop, since it has to release the lock on "this", because that monitor is also needed by the thread doing recovery. This only ever happens for readPage (not writePage), cf. call to getEmbryonicPage in WriteRAFHeader called from RAFContainer#clean. c) in other cases, the thread will call awaitRestoreChannel before reattempting IO. The logic of RAFContainer4#getEmbryonicPage has been folded into readPage in order for it to be covered by the interrupt treatement. The test Derby151Test has been removed, since it is no longer relevant. A new test, InterruptResilienceTest, fails without the patch, but should work with the patch in place. It interrupts the single app thread before doing IO, which will trip NIO and cause recovery. Even though we have only one app thread, the test still revealed concurrency issues during the development of this patch, since RawStoreThread will also do IO on the container. A note on the implementation: Sun Java NIO code (including the latest 1.6) has a bug which are worked around by the patch in two places, cf. code comments: - readFull/writeFull: if a thread has been interrupted, occasionally it closes the channel but does not throw, cf. http://webbugs.sfbay.sun.com/rt/incidentDisplay?incidentID=1854795 - readPage/WritePage: sometimes the interrupted thread throws the wrong exception: AsynchronousCloseException instead of the more specialized ClosedByInterruptException. [1] Note: DirRandomAccessFile4 also contain use of NIO, I'll address that in a later patch. I will also be adding more tests. A problem for making tests for interrupts is to get coverage without making tests unstable, so I'll wait until I have more holes plugged. Regressions worked earlier tonight in a slightly different version, rerunning now. > 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-interru
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Issue & fix info: (was: [Patch Available]) > 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-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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Attachment: derby-4741-a-04-api-interruptstatus.stat derby-4741-a-04-api-interruptstatus.diff Uploading a revised patch, derby-4741-a-04-api-interruptstatus, which takes care of the comments. hopefully. Rerunning regressions. > 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-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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Attachment: derby-4741-a-03-api-interruptstatus.stat derby-4741-a-03-api-interruptstatus.diff Uploading version a-03, minor and clerical changes only relative to a-02. > 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-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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Attachment: derby-4741-a-01-api-interruptstatus.stat derby-4741-a-01-api-interruptstatus.diff Uploading a first rev of a patch for part a): derby-4741-a-01-api-interruptstatus Regressions ran ok modulo a hang in BootLockTest. This patch contains the new helper class InterruptStatus and inserts calls to restoreIntrFlagIfSeen in before API methods' return and in the exception handling (TransactionResourceImpl#handleException). Execution of EmbedStatement#executeBatch check of interrupts and throws 08000 if seen between each statement in the batch. Note: Still, the machinery of InterruptStatus isn't used to save any interrupts, that follows in a later patch, so this patch doesn't change behavior. The focus here is on the correct placement of calls to restoreIntrFlagIfSeen in the API. Reviews appreciated! Patch details: - iapi.util.InterruptStatus: new helper class for keeping track of detected and postponed interrupts - LanguageConnectionContext GenericLanguageConnectionContext: Methods to set/reset threads interrupt status flag to allow us to clear the thread's actual flag temporarily, and to reset it when we return to the user application, possibly by throwing an interrupted SQLException (SQL state 08000) if we cut something short. It also contains methods to save and retrieve the stack frame at the point an interrupt was detected. This is used when we throw the interrupt exception. See also its Javadoc. - TransactionResourceImpl: resurrect the thread's interrupt status flag on SQL error (called from handleException). Use lcc if available, else thread local variable. - EmbedBlob, for methods that call handleException inside synchronized on connection: use InterruptStatus.restoreIntrFlagIfSeen(lcc) before return - EmbedResultSet: for methods that call handleException inside synchronized on connection: use InterruptStatus.restoreIntrFlagIfSeen(lcc) before return - EmbedStatment: for methods that call handleException inside synchronized on connection: use InterruptStatus.restoreIntrFlagIfSeen(lcc) before return In executeBatch, use throwIf between each statement in the batch: if we saw an interrupt, stop execution of batch. Note that if we do throw, restoreIntrFlagIfSeen will be called in the finally block, but it is idempotent, so no harm is done. It is necessary in case we saw an interrupt in the last statement of the batch. - EmbedDatabaseMetaData: for methods that call handleException inside synchronized on connection: use InterruptStatus.restoreIntrFlagIfSeen(lcc) before return - EmbedPreparedStatement: for methods that call handleException inside synchronized on connection: use InterruptStatus.restoreIntrFlagIfSeen(lcc) before return - EmbedConnection.java: for methods that call handleException inside synchronized on connection: use InterruptStatus.restoreIntrFlagIfSeen(lcc) before return For createDatabase, use InterruptStatus.restoreIntrFlagIfSeen() which inspects the thread local variable. This should catch I/O interrupts seen during the database creation phase. Special handling in #close to make sure we access lcc while it is still available. > 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-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 exe
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Attachment: derby-4741-all+lenient+resurrect.stat derby-4741-all+lenient+resurrect.diff A final version of the experimental patch, derby-4741-all+lenient+resurrect uploaded. Main changes: - use lcc to store interrupt status for a session thread. If not available fall back on a thread local. - resurrect the interrupt flag before returning to user app always, if we throw or not (see next item) - don't throw if an API operation ran to completion without trouble, even if we did see an interrupt flag The ad hoc InterruptTest and JUnit Derby151Test should run OK on both Solaris and Windows now. The internal behavior is somewhat different since the JRE on Solaris throws InterrupedIOException in more cases, cf. 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-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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Attachment: MicroAPITest.java > 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-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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lily Wei updated DERBY-4741: Attachment: derby.log Thanks Dag for giving such details about each change. It definitely helps people like me to learn and understand more. The patch is getting big and complicated. However, I run mailjdbc again the latest derby-4741-nio-container+log+waits+locks+throws, the test run into Error ERROR 40001: A lock could not be obtained due to a deadlock. derby.log is attached for reference. Do we need InterruptException on synchronized (slaveRecoveryMonitor) in LogToFile.recover(...)? Will change interrupt exception to statement level rather than session level require more code changes? Such as code in impl/store/raw/xact/* I was just thinking statement level is more user friendly to application users. > 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-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, 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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Attachment: derby-4741-nio-container+log+waits+locks+throws.diff Uploading the last patch again (derby-4741-nio-container+log+waits+locks+throws) - it had a small bug that broke LogSwitchFail.unit, fixed now ;-) > 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-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, 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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Attachment: (was: derby-4741-nio-container+log+waits+locks+throws.diff) > 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-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, 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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[
https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dag H. Wanvik updated DERBY-4741:
-
Attachment: derby-4741-nio-container+log+waits+locks+throws.stat
derby-4741-nio-container+log+waits+locks+throws.diff
Uploading another experimental patch,
derby-4741-nio-container+log+waits+locks+throws.
The change now is
- some further generalizing of recovery logic in RAFContainer4, the readPage
logic was missing some stuff I had added for writePage
- introduced InterruptTest#throwIf, which is a helper method to check & reset
the thread's interrupt status and throw an SQLException (08000 for now) if set.
- added throwIf next to Query timeout logic in
BasicNoPutResultSetImpl#checkCancellationFlag
- added throwIf before all returns in impl/jdbc/*.java in methods which call
(directly or indirectly) handleException(t), typically this pattern:
:
InterruptTest#throwIf()
return;
} catch (Throwable t) {
throw handleException(t);
This will make sure Derby throws if it ever did see an interrupt during
operation, which was intercepted for safety and postponed till a "safe place".
This is a "catch-all", though, and I'll look for other places closer to the
originating sites (container I/O, log I/O) so Derby could throw earlier.
For example, commit can now throw if we see an interrupt during writing to log,
cf. call to throwIf in EmbedConnection#commit.
Currently all interrupts throw 08000 which is session level, and none yet set
the thread's intr flag. I will go over all usages of 08000 and set the flag
next if we agree that's the right thing to do. Note that Derby151Test fails
now, but InterruptTest should work and report all interrupts Derby see (some
interrupts happen while the test is in application code; this is called out in
the test's results). Btw, InterruptTest is not yet a JUnit test..
The patch is getting a bit large and unwieldy now, but not to worry, the patch
is just a proof of concept, I'll break it down into smaller pieces before any
proposed commit. Rerunning regressions.
I see Lily would prefer statement level error, rather than session level. I am
sticking to session level for now since that's what the exisiting 08000
currently is. I'll go over the remaining *existing* usages of 08000 which I
didn't already replace with "InterruptStatus.setInterrupted" + retry logic. If
all are ok to replace, we could probably choose to change the exception to
statement level rather than session level. If not, it might be confusing to
have two kinds of SQLExceptions for interrupts, with different severity...
> 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-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, 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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Attachment: derby-4741-nio-container+log+waits+locks-2.stat derby-4741-nio-container+log+waits+locks-2.diff Attaching derby-4741-nio-container+log+waits+locks-2, which adds more interrupt recovery logic, mainly to LogToFile.java and LogAccessFile. With this version I have not yet been able to make crash the database (i.e. provoke a database level error) using the three run modes of InterruptedTest - default, i.e. write, read and lock, so we are gettting more resilient. Only interrupted lock waits are added as new Derby exception cases yet, I'll start looking into where to throw more seriously now. Indeed, some existing cases where we did throw in LogToFile, don't throw in the current patch, we just take a note and retry. > 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-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, 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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lily Wei updated DERBY-4741: Attachment: derby.log Thanks to Dag for fixing this bug. It will benefit a lot of customers. As for making the exception on either session-level or statement level, I will prefer to have it stop a run-away query and have the exception jut s statement failed. For most web application, it could be easier to rewrite the interrupt near statement than session perspective. As test for nio+container+log+waits+locks, it also passed suites.all on my windows 7 machine. However, when running mailjdbc tests, the test got exception on Error 40XD1: Container was opened in read-only mode for Browsing thread, on Error '-1:java.lang.ArrayIndexOutOfBoundsException' for Backup Thread. I am not totally sure why the different behavior for this patch. However, with derby-4741-nio-container+log patch, mailjdbc get deadlock exception. I am attach derby.log for reference point. > 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-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, 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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Attachment: derby-4741-nio-container+log+waits+locks.stat derby-4741-nio-container+log+waits+locks.diff Uploading a new version of the experimental patch, derby-4741-nio-container+log+waits+locks, which a) handles interrupts during lock wait b) retries when LogToFile fails during call to switchLogFile#preAllocateNewLogFile's call to syncFile, which I also saw, but there are probably more places where logging can fail c) adds a "lock" argument to InterruptTest to test safe throws for a) > 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-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, > 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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mike Matrigali updated DERBY-4741: -- so far your approach seems fine to me, and I think will help a lot of customers. I was wondering if you have a high level goal. Basically what should derby do when it encounters an interrupt. 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. 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. 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. Ultimately do you plan on always reenabling the interrupt after retrying or getting to a safe place? 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. 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. > 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-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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Attachment: derby-4741-nio-container+log+waits.stat derby-4741-nio-container+log+waits.diff Uploading a revised experimental patch, derby-4741-nio-container+log+waits, which intercepts and saves away interrupts in - LogToFile#flush, when a thread is waiting for another thread to flush the log. - BasePage#setExclusive (2 places) - BasePage#setExclusiveNoWait It also fixes a bug in NIO getEmbryonicPage; the new implementation tried to decrypt when reading the embryonic page if the database were encrypted. With these changes in place, the next issue that I sometime see is that we can get interrupted waiting for a lock. java.lang.InterruptedException at java.lang.Object.wait(Native Method) at org.apache.derby.impl.services.locks.ActiveLock.waitForGrant(ActiveLock.java:118) at org.apache.derby.impl.services.locks.ConcurrentLockSet.lockObject(ConcurrentLockSet.java:469) In turn this led to continual failure because I hit this ASSERT: at org.apache.derby.shared.common.sanity.SanityManager.THROWASSERT(SanityManager.java:147) at org.apache.derby.impl.services.locks.LockControl.addLock(LockControl.java:276) Knut suggested to me we try to treat this situation similarly to how we handle lock time-outs and just throw an interrupted exception at safe place. Sounds good to me. > 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-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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Attachment: xsbt0.log.gz > 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-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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Attachment: derby-4741-nio-container+log.stat derby-4741-nio-container+log.diff Uploading derby-4741-nio-container+log, which builds on the previous experimental patch in the following ways: - Adds logic to recover when switching the log file gets interrupted (seen on Windows using Derby151Test). The retry had to precolate up from the NIO code, so I use an internal exception (temporarily borrow an exisiting one; should make a new one later) - Makes RAFContainer4#getEmbryonicPage use a minion of readPage, so getEmbryonicPage can take advantage of the recovery machinery as well (it previously did a direct call to readFull, which made it vulnerable to being interrupted; this was also seen on Windows. Unfortunately, the latter could lead to deadlocks, because when getEmbryonicPage is called from writeRAFHeader, the thread has a lock on "this". If another thread is has been interrupted and is about to do recovery, it would get stuck on waiting for the monitor on "this", while the getEmbryonicPage reader would get stuck on waiting on recovery to finish. To solve this, I had to let reads from getEmbryonicPage throw an internal exception so it can back out and release the monitor on "this" (in RAFContainer#clean), and do a retry from that level. The patch is just a snapshot of my experiments, only intended so people could comment on the approach. > 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-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 > > > 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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Attachment: derby-4741-nio-container-2b.stat derby-4741-nio-container-2b.diff Uploading a modified version of the experimental patch, nio-container-2b, which also includes a standalone test I have been using to flush out effects of interrupts on threads. > 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-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 > > > 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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Issue & fix info: [Patch Available] > 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-nio-container-2.diff, > derby-4741-nio-container-2.log, derby-4741-nio-container-2.stat > > > 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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Attachment: derby-4741-nio-container-2.log derby-4741-nio-container-2.stat derby-4741-nio-container-2.diff Uploading an experimental patch which upon seeing the container channel interrupted/closed, closes and reopens the container to allow completion of the I/O. Using a modified Derby151Test, the trace on my box (OpenSolaris snv_148, Java 1.6) shows how the RAFContainer4.java I/O code recovers. When an interrupt is detected (in the form of an interrupted channel), the thread's interrupt flag is tucked away in a thread local variable for now, and the flag is reset, so the thread can continue and retry the I/O operation when the container has been resurrected. The idea is that the thread local variable might be checked "higher up" somewhere, where throwing an exception would not make the database go down. During this investigation, I have found numerous other locations at which an interrupt will make Derby go down, though, so RAFContainer4.java (or in deed NIO) is not the only weak spot we have. Running the test on Windows, I see Derby choke on trying to switch log files, cf the enclosed derby.log file "derby-4741-nio-container-2.log" due to seeing a ChannelClosedException on the log file (NIO channel.force). > 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 > Attachments: derby-4741-nio-container-2.diff, > derby-4741-nio-container-2.log, derby-4741-nio-container-2.stat > > > 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.
[jira] Updated: (DERBY-4741) Make Derby work reliably in the presence of thread interrupts
[ https://issues.apache.org/jira/browse/DERBY-4741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dag H. Wanvik updated DERBY-4741: - Issue Type: Bug (was: Improvement) Bug behavior facts: [Regression] Yes, I agree, Knut. Just did it :) > 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 > > 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.
