[
https://issues.apache.org/jira/browse/DERBY-5692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13257440#comment-13257440
]
Knut Anders Hatlen commented on DERBY-5692:
-------------------------------------------
Don't know if that's why the test behaves differently, but Derby uses a
different implementation of the lock manager on 1.4.2 (since
java.util.concurrent.* is only available on 1.5 and later).
> 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
