[
https://issues.apache.org/jira/browse/DERBY-1764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12614917#action_12614917
]
Kathey Marsden commented on DERBY-1764:
---------------------------------------
I looked a little at the Windows failure removing the database after the
encrypted run. I verified that the database is being shutdown normally (we
get the database shutdown message). I tried inserting a sleep for 10 seconds
after the shutdown and before the directory removal. I tried inserting a gc()
after the shutdown and before removal and still got the same failure. It
seems there is some sort of bug shutting down the encrypted database that it
hangs onto resources. I have been running with IBM 1.5. Monday I will try
with other JVM's and also see if I can get a reproducible test case for the
removal problem outside of this test. If anyone has any ideas what is going
on or other tips I would most appreciate it. I can reproduce two out of three
times with the multi.StressMulti10x1 test.
One more thing. The file we are unable to remove seems to vary, for instance on
one run it was:
1) StressMultiTest:encryptedjunit.framework.AssertionFailedError:
C:\test\system\singleUse\oneuse0\seg0\c420.dat
and on another
1) StressMultiTest:encryptedjunit.framework.AssertionFailedError:
C:\test\system\singleUse\oneuse0\seg0\c400.dat
Don't know if that makes any difference.
> Rewrite stress.multi as a JUnit test
> ------------------------------------
>
> Key: DERBY-1764
> URL: https://issues.apache.org/jira/browse/DERBY-1764
> Project: Derby
> Issue Type: Test
> Components: Test
> Reporter: Knut Anders Hatlen
> Assignee: Erlend Birkenes
> Attachments: derby-1764-3a-whitespace_changes.diff,
> derby-1764-derby.log, DERBY-1764-Review.diff, DERBY-1764-V1.diff,
> DERBY-1764-V2.diff, DERBY-1764_4.diff
>
>
> Currently, stress.multi consists of a number of sql scripts that are run in
> ij. It often fails with cryptic error messages, and since it uses ij, there
> is often no stack trace. It would be very useful to rewrite the test in JUnit
> so that we can get better error messages and stack traces when it fails.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
