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-3655) errror in nightly regression test: LobStreamsTest:encryptedjunit.framework.AssertionFailedError: f:\jartest\JarResults.2008-04-29\ibm16_suites.All\system\singleUse\oneuse1e\tmp\lob6165.tmp
Date Fri, 26 Sep 2008 19:55:44 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12634983#action_12634983

Knut Anders Hatlen commented on DERBY-3655:

Thanks for doing the research, Kathey. So the problem seen from the users' perspective is
that they can't necessarily delete the database until finalization has been performed after
the database shutdown if they have accessed lobs.

I don't know what's the best way to fix this, but I would strongly oppose forcing gc and finalization
as part of the normal commit/rollback logic as it is not guaranteed to have any effect and
may have a significant performance impact. Doing it as part of the database shutdown wouldn't
be that problematic, but I feel that we should try to avoid explicit gc if we could.

One thought is that LOBStreamControl could use a cache (instance of CacheManager) of open
file descriptors used for temporary lobs, kind of like the container cache. If the file descriptor
is in the cache when LOBStreamControl needs it, it can just fetch it. Otherwise, the cache
would have to reopen the temporary file and return the new file descriptor. When a [BC]lob
object is finalized, it invalidates the cache entry and closes the file descriptor. If the
[BC]lob object is gc'ed but not finalized when the database is shut down (as in the problem
case in this issue), we'll still have a reference to the file descriptor in the file descriptor
cache, and we can close it as part of the database shutdown.

Just a half-baked idea for now, but I think it should work, with the additional benefit of
reducing the peak in the number of open file descriptors we can get when we open many lobs
in the same transaction without explicitly freeing them, and also reducing the reliance on
gc to free up resources for us.

> errror in nightly regression test: LobStreamsTest:encryptedjunit.framework.AssertionFailedError:
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>                 Key: DERBY-3655
>                 URL: https://issues.apache.org/jira/browse/DERBY-3655
>             Project: Derby
>          Issue Type: Bug
>          Components: Regression Test Failure
>    Affects Versions:,
>         Environment: OS: Windows, Test: v10_4 branch insane jars, ibm16 jvm
> OS: Windows, Test: v10_3 branch insane jars, ibm142 jvm
>            Reporter: Mike Matrigali
>            Assignee: Kathey Marsden
> There was 1 failure:
> 1) LobStreamsTest:encryptedjunit.framework.AssertionFailedError: f:\jartest\JarResults.2008-04-29\ibm16_suites.All\system\singleUse\oneuse1e\tmp\lob6165.tmp
> 	at org.apache.derbyTesting.junit.DropDatabaseSetup.removeDir(DropDatabaseSetup.java:130)
> 	at org.apache.derbyTesting.junit.DropDatabaseSetup.removeDir(DropDatabaseSetup.java:128)
> 	at org.apache.derbyTesting.junit.DropDatabaseSetup.access$000(DropDatabaseSetup.java:35)
> 	at org.apache.derbyTesting.junit.DropDatabaseSetup$1.run(DropDatabaseSetup.java:105)
> 	at java.security.AccessController.doPrivileged(AccessController.java:202)
> 	at org.apache.derbyTesting.junit.DropDatabaseSetup.removeDirectory(DropDatabaseSetup.java:102)
> 	at org.apache.derbyTesting.junit.DropDatabaseSetup.removeDirectory(DropDatabaseSetup.java:98)
> 	at org.apache.derbyTesting.junit.DropDatabaseSetup.removeDatabase(DropDatabaseSetup.java:91)
> 	at org.apache.derbyTesting.junit.DropDatabaseSetup.tearDown(DropDatabaseSetup.java:77)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:20)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)
> 	at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
> 	at junit.extensions.TestSetup.run(TestSetup.java:23)

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message