db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-5108) Intermittent failure in AutomaticIndexStatisticsTest.testShutdownWhileScanningThenDelete on Windows
Date Sat, 12 Mar 2011 09:15:59 GMT

    [ 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

Mime
View raw message