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

Knut Anders Hatlen commented on DERBY-5108:
-------------------------------------------

Thanks for testing the patch, Lily!

> Does this approach fulfill the top down shutdown supported by the 
> architecture?

Yes, I think so. The istat service is shut down from the data dictionary, which 
is top-down. That was done before as well, but the actual worker thread would 
be left running until it finished by itself. With the patch, stop() won't 
complete until the worker thread is done, so when the higher leveles proceed in 
the shutdown code, we know that the istat thread won't be causing any bad 
interactions.

> 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.0.0
>         Environment: Windows platforms.
>            Reporter: Kristian Waagan
>            Assignee: Mike Matrigali
>            Priority: Blocker
>         Attachments: 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

Reply via email to