[
https://issues.apache.org/jira/browse/DERBY-5649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Myrna van Lunteren closed DERBY-5649.
-------------------------------------
Resolution: Fixed
Fix Version/s: 10.9.0.0
10.8.2.3
I don't intend to do more work on this at this time.
> make improvements to nstest so it's easier to run/analyze/debug
> ---------------------------------------------------------------
>
> Key: DERBY-5649
> URL: https://issues.apache.org/jira/browse/DERBY-5649
> Project: Derby
> Issue Type: Task
> Components: Test
> Affects Versions: 10.9.0.0
> Reporter: Myrna van Lunteren
> Assignee: Myrna van Lunteren
> Priority: Minor
> Fix For: 10.8.2.3, 10.9.0.0
>
> Attachments: DERBY-5649.diff1
>
>
> The system test nstest ran into a number of error situations during the
> 10.8.2 QA cycle. However, some are known, some were found to be pre-existing
> situations (although intermittent, so we've been lucky/unlucky not to run
> into them). Some errors are expected. And some problems were indeed new.
> However, the test output is very wordy and it's complicated identifying real
> issues and sorting through the messages.
> It would be helpful to clean this up some.
> I found the following areas for easy improvement:
> - InitThread messages and Intializer.java: exited add_one_row: 1 rows
> seems like this is really the same message.
> If we eliminate one, we'll have limited that part of the output by 50%.
> - TesterThreads - seems to send one message re 'attempting to', one for
> fail/success.
> Again, if we eliminate the 'attempted to' messages, we'd have made the
> output smaller.
> - db_util.pick_one - seems also unnecessary - can this be combined with the
> insert / update / delete messages that are using the picked row?
> - ERROR 22003 -> The resulting value is ourside the range for data type
> DECIMAL/NUMERIC(5,0)
> The column is t_decimal(decimal), i.e. a decimal(5,0). The value it's
> attempting to insert is clearly
> not suitable. From the code (in dbUtil) it does not look like this
> was intended to be a negative test.
> Eliminating the error (and its corresponding stack prints) would
> probably make the output considerably smaller
> and make looking for interesting errors easier.
> - There seems to be a section that can be used as a smaller test case, but
> you need to comment out the 'normal' settings, and uncomment out these
> settings. It would make more sense to make the small configuration as an
> option.
> - With a small configuration, the backup thread would run on when all other
> tests are done, because it has the same
> value for MAX_ITERATIONS, but in contrast to the tester threads, the
> backup threads runs every 10 minutes.
> Thus, when all other threads are done, the backup threads continue until
> 50x10 minutes have passed (plus the time it takes to actually do the backup,
> re-encrypt, restore). So it would make more sense to finish the backup
> threads if there is no further activity to the database.
> - there are some typos and strange line-spacings making some comments hard to
> read.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira