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] Updated: (DERBY-5108) Intermittent failure in AutomaticIndexStatisticsTest.testShutdownWhileScanningThenDelete on Windows
Date Thu, 10 Mar 2011 23:25:59 GMT

     [ https://issues.apache.org/jira/browse/DERBY-5108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Mike Matrigali updated DERBY-5108:
----------------------------------

              Priority: Blocker  (was: Major)
    Bug behavior facts: [Regression, Regression Test Failure]  (was: [Regression Test Failure])

I am actively working on this one.  Right now I am concentrating on SANE, classes, windows
failure of just this one fixture.  For me on my laptop this fails every time.
Unless anyone protests I am going to check in a change that disables just this one fixture
while I am working on it.  I have verified that the file that is the problem is the
data file that istat is scanning when the shutdown happens.  It stuck around for over an hour
so I am going to assume the resource is stuck open at least until the thread
that started the server goes away and in worst case until the jvm comes down.  I 

I am marking this a regression, because a user previous to 10.8 that shuts down when his threads
are doing nothing won't see this.  But in 10.8 istat might be running
and he will run into it.  I could see this leading to problems with subsquent ddl which has
to do deletes or renames of the associated table.

My current guess is that DERBY-5037 fixed the symptom but shutdown is still failing and leaving
a real resource problem.  I still need to do some more debugging to 
verify what is going on.  In my case I am consistently getting the ASSERT.  But I believe
we see the issue in nightly runs against SANE=false so it is not specific to stuff
we do in ASSERT logic.  I am hoping that fixing the SANE path will apply to the SANE=false
path also.  

Logically it seems like what should happen on "clean" shutdown is first user threads should
be shutdown, then istat, and finally store.  I wonder if in 10.8 we can take advantage of
the interrupt work to quickly and safely shutdown the user and istat threads?

> 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