Myrna van Lunteren (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-1462?page=comments#action_12420945 ]
Myrna van Lunteren commented on DERBY-1462:
-------------------------------------------
I do not believe this is a test harness issue.
If I run these steps with another jvm, these warnings do not appear.
I 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 experimented, and I can make the warning appear with this ibm 1.3.1 SR10 with
only ij, but not with another jvm by doing the following:
- start ij:
java org.apache.derby.tools.ij
ij>connect 'jdbc:derby:tstdb;create=true';
ij> create table t1 (c1 int);
ij> disconnect;
ij> exit;
- ls tstdb and observe there is no db.lck file
- start ij again, select from t, and ctrl-c out:
java org.apache.derby.tools.ij
ij> connect 'jdbc:derby:tstdb';
ij> select * from t1;
CTRL-C
- ls tstdb and observe there is a db.lck file now
- start ij again, and connect again, and see that only with ibm 1.3.1 do you
see the warning.
I have no jdk131 installed on the machine I was doing this on. Maybe someone
else can verify this behavior for that.
I worked on making _sed.properties files for all the affected tests (for 10.2, we have one extra tests failing - st_derby715.java) but this does not work for the stress tests, and possibly this is not the right thing to do in the first place.
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.
