[
https://issues.apache.org/jira/browse/DERBY-4213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12745719#action_12745719
]
Myrna van Lunteren edited comment on DERBY-4213 at 8/20/09 4:18 PM:
--------------------------------------------------------------------
I'm attaching a patch which tries to address the growth of the database in
sttest by the following:
- adjust the compress() method with syntax that works (using
SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE) and hang it in the test.
The method Sttest.compress wasn't used before.
As I didn't think it mattered much where this was called, but I didn't want
it very often, I hung this right after a Memcheck.
- adjust the delete code to pick rows by doing select id from Datatypes where
id >= <randomnumber> and if there is no suitable row in the database, try with
a different random number.
Before, it was using the exact random number, and it was adding the
resulting id value to the list, resulting in lots of attempts to delete a row
with id '0'.
Now, the likelihood of finding a row is much better, and so more rows
actually get deleted.
With this code, the database stays fairly small in my test runs (granted, I
built with both targetmin and targetmax smaller).
Some comments:
- I also updated the utils/CompressTable with working syntax for
in-place-compress, however, as far as I can tell, this class, or its methods,
are not used anywhere.
- Sometimes, (especially with smaller targetmin/max) the code that builds a
list of rows to be deleted, will end up with a number of identical ids to be
deleted. I figured this was ok, it's still better than hoping for a random
number to exist in the database.
- I noticed various minor inconsistencies that I don't intend to address at
this time, for instance:
- there are (still) some unused objects floating around.
- sometimes, the message 'hit targetmax with <rowcount> ...' has a null
date. I didn't look into this as it seemed unrelated to my changes.
Review is welcome, but I plan to commit this fairly soon...If there are no
comments on this patch, I'll commit it tomorrow and backport to 10.5.
was (Author: myrna):
I'm attaching a patch which tries to address the growth of the database in
sttest by the following:
- adjust the compress() method with syntax that works (using
SYSCS_UTIL.SYSCS_INPLACE_COMPRESS_TABLE) and hang it in the test.
The method Sttest.compress wasn't used before.
As I didn't think it mattered much where this was called, but I didn't want
it very often, I hung this right after a Memcheck.
- adjust the delete code to pick rows by doing select id from Datatypes where
id >= <randomnumber> and if there is no suitable row in the database, try with
a different random number.
Before, it was using the exact random number, and it was adding the
resulting id value to the list, resulting in lots of attempts to delete a row
with id '0'.
Now, the likelyhood of finding a row is much better, and so more rows
actually get deleted.
With this code, the database stays fairly small in my test runs (granted, I
built with both targetmin and targetmax smaller).
Some comments:
- I also updated the utils/CompressTable with working syntax for
in-place-compress, however, as far as I can tell, this class, nor its methods,
are used anywhere.
- Sometimes, (especially with smaller targetmin/max) the code that builds a
list of rows to be deleted, will end up with a number of identical ids to be
deleted. I figured this was ok, it's still better than hoping for a random
number to exist in the database.
- I noticed various minor inconsistencies that I don't intend to address at
this time, for instance:
- there are (still) some unused objects floating around.
- sometimes, the message 'hit targetmax with <rowcount> ...' has a null
date. I didn't look into this as it seemed unrelated to my changes.
Review is welcome, but I plan to commit this fairly soon...If there are no
comments on this patch, I'll commit it tomorrow and backport to 10.5.
> sttest needs to be adjusted to not run out of disk space
> --------------------------------------------------------
>
> Key: DERBY-4213
> URL: https://issues.apache.org/jira/browse/DERBY-4213
> Project: Derby
> Issue Type: Improvement
> Components: Test
> Affects Versions: 10.5.1.1, 10.6.0.0
> Reporter: Myrna van Lunteren
> Assignee: Myrna van Lunteren
> Priority: Minor
> Attachments: DERBY-4213.diff1
>
>
> After eliminating some NullPointerExceptions for 10.5.1.1 (which I noticed
> with 10.5.1.0 testing but had also been present with 10.4.2.0) the sttest
> runs out of disk space before all threads are done.
> Before, with the NPEs, the test would run its course in a day or two.
> The test should be adjusted, with perhaps more deletes, so that it will no
> longer run out of disk space.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
