[
https://issues.apache.org/jira/browse/DERBY-5222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13032849#comment-13032849
]
Kristian Waagan commented on DERBY-5222:
----------------------------------------
I'm puzzled by the output from the delete method and the test log file, but
here is what I see:
a) The first round of attempted deletes fails to delete 37 files.
b) The next round fails with an assert because the database root directory
isn't found:
junit.framework.AssertionFailedError: directory doesn't exist:
/export/home/tmp/jagtmp/autoderbyN_regression/compatibility_3/log/wombat
At this point, these facts supports at least these two theories (assuming the
Derby delete method is correct):
1) A "delete race" taking place (directory/files deleted from two or more
threads/processes concurrently).
2) A bug in the VM, either misreporting the outcome of the deletions, or
allowing non-empty directories to be deleted.
However, looking at the files that couldn't be deleted, one sees that they are
all stub files (starting with 'd' instead of 'c'). I don't know the specifics,
but I believe stub files are deleted by Derby itself at certain times (for
instance during/after a checkpoint?). That makes this bug a timing and/or order
sensitive bug with respect to when the files are attempted deleted. One
explanation is that Derby is still shutting down when the delete method obtains
the list of files to delete, and when it tries to delete the stub files they
have already been deleted by Derby.
This is merely a hypothesis, and it depends on whether the database server is
shut down completely when the deletion begins.
Anyone with knowledge about the runtime characteristics of the upgrade test
around?
> 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
