You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Knut Anders Hatlen (JIRA)" <ji...@apache.org> on 2012/11/22 12:01:00 UTC
[jira] [Commented] (DERBY-6001) ErrorMessageTest assert failure:
Only one of the waiters should be aborted
[ https://issues.apache.org/jira/browse/DERBY-6001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502717#comment-13502717 ]
Knut Anders Hatlen commented on DERBY-6001:
-------------------------------------------
This happened again. With the improved diagnostics, I found in the log that one of the threads failed with the expected deadlock exception, and the other thread failed with a timeout exception. So it seems like the difference between the deadlock timeout and the regular wait timeout is too small on this platform. The deadlock is detected, as expected, but the chosen victim is not terminated quickly enough to prevent the other transaction from timing out.
Since this test case is not expected to produce a timeout, I think we can increase the lock timeout without slowing it down in the common case. That should give slower machines more time to kill the victim before the timeout expires. Faster machines don't need to wait for the timeout to happen, so they should be unaffected.
> ErrorMessageTest assert failure: Only one of the waiters should be aborted
> --------------------------------------------------------------------------
>
> Key: DERBY-6001
> URL: https://issues.apache.org/jira/browse/DERBY-6001
> Project: Derby
> Issue Type: Bug
> Components: Test
> Affects Versions: 10.10.0.0
> Environment: Java SE Embedded 7u6 for ARM
> Reporter: Knut Anders Hatlen
> Attachments: d6001-1a-diagnostics.diff
>
>
> I occasionally see this test failure on some ARM devices:
> junit.framework.AssertionFailedError: Only one of the waiters should be aborted
> at org.apache.derbyTesting.functionTests.tests.lang.ErrorMessageTest.testDeadlockTimeout(ErrorMessageTest.java:206)
> at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:117)
> at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBareOverridable(BaseJDBCTestCase.java:424)
> at org.apache.derbyTesting.junit.BaseJDBCTestCase.runBare(BaseJDBCTestCase.java:441)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> at junit.extensions.TestSetup.run(TestSetup.java:25)
> at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> at junit.extensions.TestSetup.run(TestSetup.java:25)
> at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> It's probably timing-dependent, since the failing test case runs two threads, and the devices where it's seen are slow compared to most other test servers.
--
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