[
https://issues.apache.org/jira/browse/DERBY-5108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13005562#comment-13005562
]
Kristian Waagan commented on DERBY-5108:
----------------------------------------
Thanks for looking into this, Mike.
If you enable istat logging and tracing, you should be able to see which
exception/error is raised when the istat daemon is shut down (i.e. is it always
being raised in the same place?)
Kathey, even though I agree this could be extremely problematic, there are some
points to consider:
o the istat daemon must be doing work as the database is shut down
o the bug is timing dependent (it doesn't fail every time on the regression
test machines, nor on my Windows Vista quad core)
o the user must try to delete the database files
o affects Windows platforms only
With the points above, this issue is still not a blocker for me, especially
since the feature can be disabled. I still think this issue is the most
important istat bug to fix, so it would be great if it made it into 10.8.
It is unclear to me at this point what happens resource-wise if you just skip
the delete-step, reboot the database and repeat the sequence (without killing
the JVM).
One thing that will definitely make it a blocker is if the database can't be
booted and/or be written into after the bug occurs (again, without killing the
JVM, as would typically by the case in appserver environments).
> 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
