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] Updated: (DERBY-4825) Assert failure in LargeDataLocksTest.testGetCharacterStream() because of wrong number of locks
Date Wed, 06 Oct 2010 21:59:31 GMT

     [ https://issues.apache.org/jira/browse/DERBY-4825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Knut Anders Hatlen updated DERBY-4825:

    Attachment: postcommit.diff

I found that the background thread obtains exclusive locks on rows the SYSSTATEMENTS table
while doing post-commit work, so I suspect that's what making these locks turn up intermittently
in the lock table.

The attached patch makes assertLockCount() wait for post-commit work to complete before it
counts the locks. On a machine where LargeDataLocksTest has failed every time I've run it
as part of suites.All, the entire test suite ran cleanly with the patch. I'll rerun suites.All
to verify that it wasn't just pure luck that made it pass this one time. (I have never seen
the failure outside of suites.All, so I don't have any quicker way to verify it.)

If we make this change, I don't think we should move assertLockCount() to BaseJDBCTestCase
just yet since it now depends on a stored procedure that won't be available in general.

> Assert failure in LargeDataLocksTest.testGetCharacterStream() because of wrong number
of locks
> ----------------------------------------------------------------------------------------------
>                 Key: DERBY-4825
>                 URL: https://issues.apache.org/jira/browse/DERBY-4825
>             Project: Derby
>          Issue Type: Bug
>          Components: Services
>    Affects Versions:
>         Environment: FreeBSD 8.1, i386
> Diablo Java(TM) SE Runtime Environment (build 1.6.0_07-b02)
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>            Priority: Minor
>         Attachments: dump-locks.diff, postcommit.diff
> I saw this failure when running suites.All on the release candidate:
> 1) testGetCharacterStream(org.apache.derbyTesting.functionTests.tests.jdbcapi.LargeDataLocksTest)junit.framework.AssertionFailedError:
expected:<0> but was:<3>
> 	at org.apache.derbyTesting.functionTests.tests.jdbcapi.LargeDataLocksTest.testGetCharacterStream(LargeDataLocksTest.java:72)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:109)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
> 	at junit.extensions.TestSetup.run(TestSetup.java:27)
> 	at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> The assertion expects the lock table to have zero locks, but it finds three.
> The test succeeded when I later ran it 100 times outside of suites.All.
> The failure looks similar to DERBY-4301, but I saw this in a pure 10.6 environment, whereas
DERBY-4301 happened in a mixed 10.3/10.5 environment. Also, DERBY-4301 is consistently reproducible,
whereas this failure appears to be intermittent.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message