[
https://issues.apache.org/jira/browse/DERBY-5108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13006010#comment-13006010
]
Knut Anders Hatlen commented on DERBY-5108:
-------------------------------------------
Engine shutdown interrupts all threads that are active inside Derby code. I'm
wondering if that's the interrupt the istat thread is experiencing. DERBY-4920
was similar, only then it was a checkpoint that was interrupted by the engine
shutdown and reopened the channel. I don't know if we want to handle interrupts
differently for the istat daemon than we do for other threads. I'd rather see
that the reopening logic in store knew that it shouldn't attempt to reopen
channels if the engine is about to shut down. I thought it already had some
logic to take care of that, but I'm not sure.
Waiting for the istat thread before completing shutdown sounds OK. I think the
reason why it doesn't do that now, was a concern that it may take a very long
time if it's processing a large index. But shutdown also performs a checkpoint,
which may take a long time if the page cache is big. And if the istat thread is
also interrupted by the engine shutdown, it should stop rather quickly (if we
only can make it stop reopening the channel).
I'm wondering, though, if this problem is istat-specific, or if we would see
the same problem if we called SYSCS_UPDATE_STATISTICS on a large index just
before shutting down the database?
> 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
>
>
> 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
