[
https://issues.apache.org/jira/browse/DERBY-5865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13723059#comment-13723059
]
Kathey Marsden commented on DERBY-5865:
---------------------------------------
This was reported on z/os on IBM 1.7 with IBM_JAVA_OPTIONS -Xcompressedrefs
-Xgcpolicy:balanced -Xnoquickstart -Xjit
This is a slow mode and so gets into this part of the test which does alternate
checking, which checks that the time with real commit is at least 1.5 times
that of test mode. I don't know that this is a valid check in this mode where
just running is very slow and perhaps dwarfs the sync difference so that commit
is not 1.5 times greater than test mode.
// an approximation on the upper bound for time taken to do
// inserts in autocommit mode with derby.system.durability=test mode
long upperBound = 3000;
// if it takes a lot of time to do the inserts then do extra checks
// to determine if derby.system.durability=test mode is broken or not
// because we cant be sure if inserts just took a long time
// because of a really slow machine
if (timeWithTestModeCommitOn > upperBound) {
long proximityRange = 1000;
// in derby.system.durability=test autocommit on or off should
// be in same range since syncs are not happening
if (Math.abs(timeWithTestModeCommitOn - timeWithTestModeCommitOff)
> proximityRange) {
// another approximation here (1.5 times of with testmode set)
if (timeWithTestModeCommitOn > timeCommitOn
|| (timeCommitOn < (1.5 * timeWithTestModeCommitOn))) {
report("FAIL -- derby.system.durability=test mode seems to
be broken.");
report("-- In this mode one would expect that inserts with
autocommit off and on "
+ "would be in the same range as syncs are not
happening but the difference "
+ "here seems to be more than the approximate
estimated range.");
report("-- Also comparing the time taken to do the inserts
without this" +
" property set seems to be in the same"
+ " range as with this property set.");
report("-- Please note this test times inserts and
approximate estimates were " +
"considered to report this observation.");
}
}
}
> On IBM 1.7 TestDurabilityProperty fails with FAIL --
> derby.system.durability=test mode seems to be broken.
> -----------------------------------------------------------------------------------------------------------
>
> Key: DERBY-5865
> URL: https://issues.apache.org/jira/browse/DERBY-5865
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.10.1.1
> Environment: Linux trunk version: 10.10.0.0 alpha - (1362738)
> Reporter: Kathey Marsden
> Assignee: Kathey Marsden
> Labels: derby_triage10_10
>
> I saw this failure on IBM 1.7 on 7/17/2012
> http://people.apache.org/~myrnavl/derby_test_results/main/linux/testlog/ibm17/1362738-derbyall_diff.txt
> ********* Diff file derbyall/storeall/storemore/TestDurabilityProperty.diff
> *** Start: TestDurabilityProperty jdk1.7.0 storeall:storemore 2012-07-18
> 01:45:06 ***
> 1a2,5
> > FAIL -- derby.system.durability=test mode seems to be broken.
> > -- In this mode one would expect that inserts with autocommit off and on
> > would be in the same range as syncs are not happening but the difference
> > here seems to be more than the approximate estimated range.
> > -- Also comparing the time taken to do the inserts without this property
> > set seems to be in the same range as with this property set.
> > -- Please note this test times inserts and approximate estimates were
> > considered to report this observation.
> Test Failed.
> *** End: TestDurabilityProperty jdk1.7.0 storeall:storemore 2012-07-18
> 01:46:39 ***
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
