db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5108) Intermittent failure in AutomaticIndexStatisticsTest.testShutdownWhileScanningThenDelete on Windows
Date Mon, 28 Mar 2011 21:38:05 GMT

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

Mike Matrigali commented on DERBY-5108:
---------------------------------------

I tried out the latest in trunk as of 3/26/2011 and ran the AutomaticIndexStatisticsTest suite
64 times and got 61 good runs and 3 failures all in the shutdown fixture as follows:
There was 1 failure:
1) testShutdownWhileScanningThenDelete(org.apache.derbyTesting.functionTests.tes
ts.store.AutomaticIndexStatisticsTest)junit.framework.AssertionFailedError: Fail
ed to delete 3 files (root=C:\derby\s2\newout\system\singleUse\copyShutdown: C:\
derby\s2\newout\system\singleUse\copyShutdown\seg0\c481.dat (isDir=false, canRea
d=true, canWrite=true, size=22351872), C:\derby\s2\newout\system\singleUse\copyS
hutdown\seg0 (isDir=true, canRead=true, canWrite=true, size=0), C:\derby\s2\newo
ut\system\singleUse\copyShutdown (isDir=true, canRead=true, canWrite=true, size=
0)
    at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertDirectoryDeleted(Bas
eJDBCTestCase.java:1526)
    at org.apache.derbyTesting.functionTests.tests.store.AutomaticIndexStatistic
sTest.testShutdownWhileScanningThenDelete(AutomaticIndexStatisticsTest.java:188)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java
:60)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI
mpl.java:37)
    at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:112)
    at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
    at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
    at junit.extensions.TestSetup.run(TestSetup.java:23)
    at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
    at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
    at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
    at junit.extensions.TestSetup.run(TestSetup.java:23)

There didn't seem to be anything interesting in derby.log.  I think we should enable the "extra"
logging by default in
this test while there is still and issue. I would be happy to run in my environment and reproduce
if there is any 
additional logging that we think will track down the issue (even if it something we don't
want checked into the
actual codeline).  Tonight I will at least run the test with the extra logging enabled from
the command line.

> 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
>            Priority: Blocker
>         Attachments: derby-5108-2.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

Mime
View raw message