[
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.
