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-4825) Assert failure in LargeDataLocksTest.testGetCharacterStream() because of wrong number of locks
Date Tue, 05 Oct 2010 11:38:32 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12917944#action_12917944

Knut Anders Hatlen 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?

I suppose we could move this method to BaseJDBCTestCase to make it
available for other tests.

> It would also be nice to have a method do just dump the lock table
> to stdout (i.e. not doing any asserts).

I see that there are some tests with helper methods that print result
sets to stdout. Perhaps one of those can be moved to the
BaseJDBCTestCase class or the JDBC class? But I guess in most cases
where you're interested in the contents of the lock table you would
have an assert of some kind.

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