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 Tue, 05 Oct 2010 10:49:33 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: dump-locks.diff

Attaching a patch that makes LargeDataLocksTest report the contents of the lock table when
the lock count is wrong. I now see this message when I run suites.All:

junit.framework.AssertionFailedError: Unexpected lock count. Contents of lock table:
1: XID=601052 TYPE=ROW MODE=X TABLENAME=SYSSTATEMENTS LOCKNAME=(10,13) STATE=GRANT TABLETYPE=S
LOCKCOUNT=1 INDEXNAME=null 
2: XID=601052 TYPE=TABLE MODE=IX TABLENAME=SYSSTATEMENTS LOCKNAME=Tablelock STATE=GRANT TABLETYPE=S
LOCKCOUNT=1 INDEXNAME=null 
 expected:<0> but was:<2>

Exclusive locks in SYSSTATEMENTS would usually mean that someone is recompiling a trigger
or a meta-data query, I think.

> 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: 10.6.2.1
>         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
>
>
> I saw this failure when running suites.All on the 10.6.2.1 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.


Mime
View raw message