[
https://issues.apache.org/jira/browse/DERBY-5108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Waagan updated DERBY-5108:
-----------------------------------
Attachment: derby-5108-2a-early_istats_shutdown_broad.diff
Hi Dag,
There is a need to stop the istat daemon in other cases too to guarantee that
this issue will never happen. There are several criteria that must occur for
the issue to happen, and a few more to be able to observe it. Nevertheless, I
think the takeaway is that Derby will leak file handles. How/if this affects
normal Derby operation is unclear to me, and a JVM restart will clean this up.
Attaching patch 2a.
To make the fix broader, I moved the logic to stop the daemon to
DatabaseContextImpl.cleanupOnError.
Do you reckon this is sufficient, or are you aware of other location that will
bypass that code?
The regression tests ran without failures with patch 2a, but I have not yet
tested this on Windows (I'll try to start a test loop later today when I can
access a Windows machine).
Patch ready for review.
> 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
> 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
