db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1462) Test harness incorrectly catches db.lck WARNINGS generated during STORE tests and lists the tests as failed in *_fail.txt.
Date Fri, 14 Jul 2006 01:59:30 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1462?page=comments#action_12420977 ] 

Myrna van Lunteren commented on DERBY-1462:
-------------------------------------------

cut-and-paste comment on the list by Mike Matrigali:
--------------- agree, I think this a problem with these particular tests on pre 1.4
jvms, on non windows platforms - their output is different - it would
not be right to somehow get
the harness to supress every connect warning printed.  Fixing with test
specific seds is fine.

I checked all the tests below except for the stress ones, they all are
setup to run on an existing db and are coded to crash with no cleanup so
that subsequent test will run recovery.  A side effect of that crash on
pre-1.4 jvms on non windows platforms is that it leaves a lock file
around which derby can't tell
if it is an active lock file and thus the reconnect correctly prints a
warning in those cases.

The stress ones are a little puzzling, I didn't think we reconnected to
the same db - I have not really looked at how we run those tests in
the network server framework.  Is it likely we are trying to run those
tests on an existing db?
------------------------------------

I think with the stress test & networkserver the last tester gets interrupted because
of the timeout (10 minutes), so that process leaves the db.lck behind, which will cause the
final.sql to hit the WARNING, so that's to be expected too.


> Test harness incorrectly catches db.lck WARNINGS generated during STORE tests and lists
the tests as failed in *_fail.txt.
> --------------------------------------------------------------------------------------------------------------------------
>
>          Key: DERBY-1462
>          URL: http://issues.apache.org/jira/browse/DERBY-1462
>      Project: Derby
>         Type: Test

>   Components: Test
>     Versions: 10.1.2.5, 10.1.2.4, 10.1.2.3, 10.1.2.2, 10.1.2.1, 10.1.3.0, 10.1.3.1
>  Environment: IBM 1.3.1 JRE for LINUX (and possibly other JRE 1.3.1 environments)
>     Reporter: Stan Bradbury
>     Assignee: Myrna van Lunteren
>     Priority: Minor

>
> The following store tests from derbyall do not shutdown cleanly so leave the db.lck file
on disk.  This is OK! It is done by design to test recovery.  THE PROBLEM, when run on Linux
using IBM JRE 1.3.1 sp 10 the test harness 'sees' the warnings and lists the tests as having
failed.  The harness should ignore this warnings as the tests proceed and complete cleanly.
> Tests INCORRECLTY reported as failed:
> derbyall/derbynetclientmats/derbynetmats.fail:stress/stress.multi
> derbyall/derbynetmats/derbynetmats.fail:stress/stress.multi
> derbyall/storeall/storeall.fail:storetests/st_1.sql
> derbyall/storeall/storeall.fail:unit/recoveryTest.unit
>  erbyall/storeall/storeall.fail:store/LogChecksumRecovery.java
> derbyall/storeall/storeall.fail:store/LogChecksumRecovery1.java
>  erbyall/storeall/storeall.fail:store/MaxLogNumberRecovery.java
> derbyall/storeall/storeall.fail:store/oc_rec1.java
> derbyall/storeall/storeall.fail:store/oc_rec2.java
> derbyall/storeall/storeall.fail:store/oc_rec3.java
> derbyall/storeall/storeall.fail:store/oc_rec4.java
> derbyall/storeall/storeall.fail:store/dropcrash.java
> derbyall/storeall/storeall.fail:store/dropcrash2.java
> Example Error message:
> WARNING: Derby (instance xxxxFILTERED-UUIDxxxx) is attempting to boot the database csf:/local1/131TST/Store1/storeall/storerecovery/storerecovery/wombat
even though Derby (instance xxxxFILTERED-UUIDxxxx) may still be active.  Only one instance
of Derby should boot a database at a time. Severe and non-recoverable corruption can result
and may have already occurred.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message