db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren (Reopened) (JIRA)" <j...@apache.org>
Subject [jira] [Reopened] (DERBY-5649) make improvements to nstest so it's easier to run/analyze/debug
Date Thu, 15 Mar 2012 22:34:38 GMT

     [ https://issues.apache.org/jira/browse/DERBY-5649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Myrna van Lunteren reopened DERBY-5649:
---------------------------------------


I'm reopening this, to adjust the test a little more;
There's an option to run without a backup thread by setting the property -Dderby.nstest.backupRestore=false,
but when you do this, the test runs into an ArrayIndexOutOfBounds error on creating the tester
threads, which then confuses the workings of the main method so it won't finish cleanly.
In that case, the Memcheck keeps going, so just to be on the safe side, I'll add a check for
remaining test threads in the Memcheck. 

While I'm add it, I'll remove some commented-out settings that appear to be left behind from
previous configuration attempts.
                
> 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

        

Mime
View raw message