[
https://issues.apache.org/jira/browse/DERBY-4825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12917940#action_12917940
]
Kristian Waagan commented on DERBY-4825:
----------------------------------------
I have been writing similar code myself many times when debugging, and I think
it would be a nice addition to the test framework.
Do we have an appropriate home for such a method?
It would also be nice to have a method do just dump the lock table to stdout
(i.e. not doing any asserts).
> 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.
