db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5222) Compatibility tests fail to delete database directory
Date Fri, 13 May 2011 08:08:47 GMT

    [ 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

Mime
View raw message