[
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
