[ http://issues.apache.org/jira/browse/DERBY-1872?page=all ]
John H. Embretsen updated DERBY-1872:
-------------------------------------
Attachment: port-wisconsin-from-10.2.0.4-to-10.1_v2.stat
port-wisconsin-from-10.2.0.4-to-10.1_v2.zip
Attaching patch for porting the lang/wisconsin.java test from its state in
10.2.0.4 to the 10.1 branch.
This patch, 'port-wisconsin-from-10.2.0.4-to-10.1_v2.zip' ('.diff' when
unzipped), replaces the _v1, patch that was attached to DERBY-1564. There is
only one change from the _v1 patch:
* Added lang/wisc_setup.sql to lang/copyfiles.ant, so that it gets included in
the build. copyfiles.ant is no longer needed in trunk or 10.2 (DERBY-892), so
it
took me a while to figure out what caused my build problem with the _v1-patch,
and why. The build works fine with the _v2 patch.
Here is a summary of changes provided by the patch:
- renames the test from lang/wisconsin.sql to lang/wisconsin.java (DERBY-398)
- adds wisc_setup.sql support file (DERBY-398)
- removes framework-specific master files (for DerbyNet and DerbyNetClient)
(DERBY-1014)
- runs compress on tables before retreiving runtimestatistics (DERBY-937)
- adds property derby.optimizer.noTimeout=true to wisconsin_derby.properties
(DERBY-413/DERBY-937)
(I do not expect any problems related to DERBY-822 (as mentioned in the _v1
patch description), as the changes relating to the wisconsin test stems from
DERBY-1014 _in preparation for_ DERBY-822, not DERBY-822 itself.)
Please note that the patch requires several 'svn add' and 'svn delete'
commands, as shown in 'port-wisconsin-from-10.2.0.4-to-10.1_v2.stat'.
The patch is zipped because it is 3.3 MB uncompressed.
I have tested this patch by running:
* lang/wisconsin.java (10.1), single-runs in all three frameworks on
* Solaris 10 x86, Sun JVM 1.5.0_07 - passed
* Solaris 10 x86, Sun JVM 1.4.2_12 - passed
* Solaris 10 x86, Sun JVM 1.3.1_15 - passed
* derbyall on Solaris 10 x86, Sun JVM 1.5.0_07 - 1 unrelated failure,
derbynetmats/testSecMec.diff
Please review/commit if you think this adds value to the 10.1 branch.
> Backport lang/wisconsin.java at 10.2.0.4-alpha to the 10.1 branch
> -----------------------------------------------------------------
>
> Key: DERBY-1872
> URL: http://issues.apache.org/jira/browse/DERBY-1872
> Project: Derby
> Issue Type: Test
> Components: Test
> Affects Versions: 10.1.3.1
> Environment: N/A
> Reporter: John H. Embretsen
> Assigned To: John H. Embretsen
> Priority: Minor
> Fix For: 10.1.3.2
>
> Attachments: port-wisconsin-from-10.2.0.4-to-10.1_v2.stat,
> port-wisconsin-from-10.2.0.4-to-10.1_v2.zip
>
>
> Investigations relating to DERBY-1564 ("wisconsin.java test failed in
> DerbyNet or DerbyNetClient frameworks, VM for network server got
> OutOfMemoryError") revealed that comparing memory usage for the
> lang/wisconsin.[java|sql] test in 10.1.x versus 10.2.x was like comparing
> apples and oranges. After the 10.1 branch was created, several updates were
> made to the wisconsin test in trunk that were not backported to 10.1, e.g:
> * giving the optimizer unlimited time to choose query plans
> * compressing the tables to avoid the instabilities reported in DERBY-937
> Backporting the test will make it less unfair to compare 10.1 vs. 10.2 (or
> trunk) test results and memory usage, and it will make it easier to determine
> if failures (such as DERBY-1564) are regressions or not. On the other hand,
> other differences between the branches that may influence the test will
> remain, so this will not be a wonder cure.
> The failures seen in DERBY-1564 were mainly caused by bugs (DERBY-1091,
> DERBY-1614) in the test harness, causing the wisconsin test for the 10.2.0.4
> snapshot to run with low memory settings. These issues have been fixed.
> The most practical backporting approach will probably be to take the
> wisconsin test as it was in the 10.2.0.4-snapshot (SVN revision 423199), and
> port it to the current 10.1 branch. Other changes have been made to the
> wisconsin test in trunk/10.2 after 10.2.0.4, but to avoid various
> dependencies (e.g. DERBY-1609), these should not be backported.
--
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