[
https://issues.apache.org/jira/browse/DERBY-5108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Waagan updated DERBY-5108:
-----------------------------------
Issue & fix info: (was: [Patch Available])
Fix Version/s: 10.9.0.0
Thanks for looking at the patch, Dag.
I think your reasoning is sound.
Do you happen to know if other exceptions than StandardExceptions can be passed
in to cleanupOnError? What happens with InterruptedExceptions?
I assume the normal case is that all exceptions are either StandardException or
other exceptions wrapped in a StandardException such that we can ask for the
severity. In any case, if another kind of exception is passed into
DatabaseContextImpl.cleanupOnError the code to shut down the istat daemon won't
be run.
The test case testShutdownWhileScanningThenDelete ran 236 times without a
failure on a Windows machine with the patch applied (I then aborted the loop).
Committed patch 1b to trunk with revision 1133304.
I'll monitor the automated tests (Windows platforms) to see if the issue shows
itself again with this fix.
> Intermittent failure in
> AutomaticIndexStatisticsTest.testShutdownWhileScanningThenDelete on Windows
> ---------------------------------------------------------------------------------------------------
>
> Key: DERBY-5108
> URL: https://issues.apache.org/jira/browse/DERBY-5108
> Project: Derby
> Issue Type: Bug
> Components: Test
> Affects Versions: 10.8.1.2
> Environment: Windows platforms.
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Blocker
> Fix For: 10.9.0.0
>
> Attachments: derby-5108-1a-early_istats_shutdown.diff,
> derby-5108-2.diff, derby-5108-2a-early_istats_shutdown_broad.diff,
> javacore.20110309.125807.4048.0001.txt, waitOnShutdown.diff
>
>
> The test AutomaticIndexStatisticsTest.testShutdownWhileScanningThenDelete
> fails intermittently on Windows platforms because the test is unable to
> delete a database directory.
> Even after several retries and sleeps (the formula should be (attempt -1) *
> 2000, resulting in a total sleep time of 12 seconds), the conglomerate
> system\singleUse\copyShutdown\seg0\c481.dat cannot be deleted.
> For instance from
> http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.6/testing/testlog/w2003/1078855-suitesAll_diff.txt
> :
> (truncated paths)
> testShutdownWhileScanningThenDelete <assertDirectoryDeleted> attempt 1 left 3
> files/dirs behind: 0=system\singleUse\copyShutdown\seg0\c481.dat
> 1=system\singleUse\copyShutdown\seg0 2=system\singleUse\copyShutdown
> <assertDirectoryDeleted> attempt 2 left 3 files/dirs behind:
> 0=system\singleUse\copyShutdown\seg0\c481.dat
> 1=system\singleUse\copyShutdown\seg0 2=system\singleUse\copyShutdown
> <assertDirectoryDeleted> attempt 3 left 3 files/dirs behind:
> 0=system\singleUse\copyShutdown\seg0\c481.dat
> 1=system\singleUse\copyShutdown\seg0 2=system\singleUse\copyShutdown
> <assertDirectoryDeleted> attempt 4 left 3 files/dirs behind:
> 0=system\singleUse\copyShutdown\seg0\c481.dat
> 1=system\singleUse\copyShutdown\seg0 2=system\singleUse\copyShutdown
> used 205814 ms F.
> Maybe the database isn't shut down, or some specific timing of events causes
> a file to be reopened when it shouldn't have been (i.e. after the database
> shutdown has been initiated).
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
