[
https://issues.apache.org/jira/browse/DERBY-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13032896#comment-13032896
]
Knut Anders Hatlen commented on DERBY-5222:
-------------------------------------------
Thanks for those observations, Kristian!
How's this theory:
The embedded variant of the compat test doesn't wait for the forked process to
shut down before it moves on to the next version (it does wait until is sees
that the process prints "OK", but that doesn't mean every database thread has
stopped). If a checkpoint happens to be running, the forked process could be
deleting the stub conglomerates when we invoke removeDirectory().
If such a stub is deleted after removeDirectory() calls File.list() and before
it actually calls delete(), it'll fail to delete it (since it's already
deleted) and add it to the list of failed deletes. However, it will still try
to delete the parent directory, and that's successful since there aren't any
files there.
The code that deleted the directory before we switched to using
BaseTestCase.removeDirectory() would give up as soon as one of the files
couldn't be deleted, so the next test would fail because it found a
half-deleted database. BaseTestCase.removeDirectory() is on the other extreme:
it goes on trying to delete files even after it has failed to delete one, and
gets surprised when it sees that it actually had succeeded.
I can see these possible solutions (not mutually exclusive):
1) Make the compatibility test wait for the forked process to complete.
2) Stop BaseTestCase.removeDirectory() from failing if the reason why it
couldn't delete a file was that the file no longer existed.
We should probably at least do 1. Not so sure about 2, since it usually means
that there is a problem if we have a delete race, and it would be good to get
it reported.
> Compatibility tests fail to delete database directory
> -----------------------------------------------------
>
> Key: DERBY-5222
> URL: https://issues.apache.org/jira/browse/DERBY-5222
> Project: Derby
> Issue Type: Bug
> Components: Test
> Affects Versions: 10.9.0.0
> Reporter: Knut Anders Hatlen
> Attachments: d5222-1a-logging.diff
>
>
> The compatibility tests fail frequently on one platform (Solaris 10, x86
> (32-bit), Java 7 ea b131). For example here:
> http://dbtg.foundry.sun.com/derby/test/Daily/jvm1.7/testing/testlog/sol32/1100759-compatibility_diff.txt
> From what's printed to the console, it looks like it fails to delete the
> database directory:
> > Failed deleting database dir
> > '/export/home/tmp/jagtmp/autoderbyN_regression/compatibility_3/log/wombat'
> And then, when running the actual test, it fails to create the log directory
> on that location (presumably because one already exists):
> Exception in thread "main" java.sql.SQLException: Failed to start database
> 'wombat' with class loader sun.misc.Launcher$AppClassLoader@53c015, see the
> next exception for details.
> (...)
> Caused by: java.sql.SQLException: cannot create log file at directory
> /export/home/tmp/jagtmp/autoderbyN_regression/compatibility_3/log/wombat/log.
> (...)
> Caused by: ERROR XSLAQ: cannot create log file at directory
> /export/home/tmp/jagtmp/autoderbyN_regression/compatibility_3/log/wombat/log.
> at org.apache.derby.iapi.error.StandardException.newException(Unknown
> Source)
> at
> org.apache.derby.impl.store.raw.log.LogToFile.getLogDirectory(Unknown Source)
> at
> org.apache.derby.impl.store.raw.log.LogToFile.getControlFileName(Unknown
> Source)
> at org.apache.derby.impl.store.raw.log.LogToFile.boot(Unknown Source)
> at org.apache.derby.impl.services.monitor.BaseMonitor.boot(Unknown
> Source)
> at org.apache.derby.impl.services.monitor.TopService.bootModule(Unknown
> Source)
> at
> org.apache.derby.impl.services.monitor.BaseMonitor.startModule(Unknown Source)
> at
> org.apache.derby.iapi.services.monitor.Monitor.bootServiceModule(Unknown
> Source)
> at
> org.apache.derby.impl.store.raw.data.BaseDataFileFactory.bootLogFactory(Unknown
> Source)
> at
> org.apache.derby.impl.store.raw.data.BaseDataFileFactory.setRawStoreFactory(Unknown
> Source)
> at org.apache.derby.impl.store.raw.RawStore.boot(Unknown Source)
> (...)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
