[
https://issues.apache.org/jira/browse/DERBY-5692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256135#comment-13256135
]
Myrna van Lunteren commented on DERBY-5692:
-------------------------------------------
Thanks for your input, Mike,
Yes, the machine is *very* busy while running the derbyall for 1.4.2, although
likely not more heavily than while running derbyall for the other jvms...
I forgot that this test needs to be run as part of the storetests suite, so
only managed to run it 25 times by now, but if timeout is to be expected *only*
during heavy load, then I don't think running 100 times will pop it either.
The default for the storetests (as per
...tests/storetests/default_derby.properties) is currently:
derby.locks.deadlockTimeout=1
derby.locks.waitTimeout=3
I was contemplating disabling the run of this test for ibm 1.4.2 (by adding an
st_derby715_app.properties file with content: runwithibm14=false).
But if this is expected behavior on a busy machine, I can instead add a
st_derby715_derby.properties that sets:
derby.locks.deadlockTimeout=1
derby.locks.waitTimeout=60
Is that what you meant?
> intermittent test failure in storetests/st_derby715.java
> --------------------------------------------------------
>
> Key: DERBY-5692
> URL: https://issues.apache.org/jira/browse/DERBY-5692
> Project: Derby
> Issue Type: Bug
> Affects Versions: 10.8.2.3
> Environment: Windows 2008, 4 CPU, ibm 1.4.2.
> Reporter: Myrna van Lunteren
> Priority: Minor
>
> I am seeing an irregularly occurring failure with ibm 1.4.2 on one machine -
> which happens to be the only 4 CPU machine and the only one running Windows
> 2008...And I've got 10.8 nightly tests running on it.
> I have not seen this with other jvms on the same machine.
> It's possible this would also happen on trunk, but we stopped supporting
> 1.4.2 with trunk and so I do not run tests against trunk with (ibm) 1.4.2.
> When the test passes, the output contains 5 identical lines 'Got a Deadlock'.
> The test failures are of 2 kinds:
> - 1 (or more?) of the 'Got a Deadlock' lines is missing
> - we get a '40XL1' error (timeout) instead of a deadlock.
> As the second situation seems to match what DERBY-715 was about, I thought it
> worthwhile reporting as a separate JIRA. We should check it's not somehow a
> regression.
--
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
