db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-6001) ErrorMessageTest assert failure: Only one of the waiters should be aborted
Date Thu, 22 Nov 2012 11:01:00 GMT

    [ 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

Mime
View raw message