db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5638) intermittent test failure in test_05_ClobNegative when running full largedata._Suite; LobLimitsTestjava.sql.SQLException: Table/View 'BLOBTBL' already exists in Schema 'APP'.
Date Thu, 08 Mar 2012 22:45:58 GMT

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

Mamta A. Satoor commented on DERBY-5638:
----------------------------------------

The derby.log for the passed and failed runs will show that they both have lock time outs
while trying to drop the tables to get the database ready in a clean state again. The failed
version has more lock time outs than the passing version. 

It appears that CleanDatabaseTestSetup tries 5 times to drop database objects. For both passed
and failed versions, all those 5 attempts fail with lock time outs. Then for some reason,
in both failed and passed version, it appears that we try to drop the objects in network server
mode(this is what I see in derby.log for both runs. I haven't looked for where it actually
happens in the junit code). Both passing and failing derby.log show lock time out for drop
table through network server mode. But after this failure, the passing derby.log continues
to finish the large data suite with no problem. But with fail version, we get 2 more lock
timeouts for trying to drop the table in network server mode. after those lock time outs,
we get table already exists error in case of failing derby.log

Some background info on largedata._Suite
largedata._Suite runs following suits
Derby5624Test(only f windows platform)
LobLimitsLiteTest
LobLimitsTest
LobLimitsClientTest

The intermittent problem we are seeing happens while running LobLimitsTest suite. LobLimitsTest
has 5 test fixtures which get run in specific order(order is ensured through TestConfiguration.orderedSuite).
The intermittent problem is in the last of those 5 fixtures, namely test_05_ClobNegative.
As the name indicates, this test does a bunch of negative tests but it does not do a rollback
or commit at the end. test_02_BlobNegative() is the 2nd of the 5 test fixtures run by LobLimitsTest
and it does negative testing too but at the end, in the catch block for the expected exception,
it does a commit. 

I think we may be seeing lock time outs because the transaction started by test_05_ClobNegative
was never committed/rolled back and hence the locks were never released. I am going to make
just one line change in my codeline to LobLimitsTest and add rollback() to the end of test_05_ClobNegative.
I will run largedata test on my machine with that change to see how it goes. I will attach
that one line change patch for reference to this jira.

                
> intermittent test failure in test_05_ClobNegative when running full largedata._Suite;
LobLimitsTestjava.sql.SQLException: Table/View 'BLOBTBL' already exists in Schema 'APP'.
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-5638
>                 URL: https://issues.apache.org/jira/browse/DERBY-5638
>             Project: Derby
>          Issue Type: Bug
>          Components: Test
>    Affects Versions: 10.9.0.0
>         Environment: ibm 1.6 sr9 fp1, Seen on Windows XP/VMWare, and Linux (CentOS)/VMWare
>            Reporter: Myrna van Lunteren
>         Attachments: derbyFailed.log, derbyPass.log
>
>
> I've seen the following failure when running the largedata suite:
> (emb)largedata.Derby5624Test.testDERBY_5624 used 518403 ms .
> (emb)largedata.LobLimitsTest.test_01_Blob used 2422 ms .
> (emb)largedata.LobLimitsTest.test_02_BlobNegative used 31 ms .
> (emb)largedata.LobLimitsTest.test_03_Clob1 used 2375 ms .
> (emb)largedata.LobLimitsTest.test_04_Clob2 used 3234 ms .
> (emb)largedata.LobLimitsTest.test_05_ClobNegative used 516 ms .
> (net)largedata.LobLimitsTest.test_01_Blob used 5360 ms .
> (net)largedata.LobLimitsTest.test_02_BlobNegative used 32 ms .
> (net)largedata.LobLimitsTest.test_03_Clob1 used 2078 ms .
> (net)largedata.LobLimitsTest.test_04_Clob2 used 2390 ms .
> (net)largedata.LobLimitsTest.test_05_ClobNegative used 938 ms .
> (emb)largedata.LobLimitsTest.test_01_Blob used 9188238 ms .
> (emb)largedata.LobLimitsTest.test_02_BlobNegative used 109 ms .
> (emb)largedata.LobLimitsTest.test_03_Clob1 used 8116714 ms .
> (emb)largedata.LobLimitsTest.test_04_Clob2 used 2164002 ms .
> (emb)largedata.LobLimitsTest.test_05_ClobNegative used 685745 ms E
> Time: 22,320.138
> There was 1 error:
> 1) LobLimitsTestjava.sql.SQLException: Table/View 'BLOBTBL' already exists in Schema
'APP'.
> 	at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown Source)
> 	at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source)
> 	at org.apache.derby.client.am.Statement.execute(Unknown Source)
> 	at org.apache.derbyTesting.functionTests.tests.largedata.LobLimitsTest.setupTables(LobLimitsTest.java:107)
> 	at org.apache.derbyTesting.functionTests.tests.largedata.LobLimitsTest$1.decorateSQL(LobLimitsTest.java:141)
> 	at org.apache.derbyTesting.junit.CleanDatabaseTestSetup.setUp(CleanDatabaseTestSetup.java:112)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:20)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> 	at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> 	at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57)
> 	at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
> 	at junit.extensions.TestSetup$1.protect(TestSetup.java:21)
> 	at junit.extensions.TestSetup.run(TestSetup.java:25)
> Caused by: org.apache.derby.client.am.SqlException: Table/View 'BLOBTBL' already exists
in Schema 'APP'.
> 	at org.apache.derby.client.am.Statement.completeSqlca(Unknown Source)
> 	at org.apache.derby.client.am.Statement.completeExecuteImmediate(Unknown Source)
> 	at org.apache.derby.client.net.NetStatementReply.parseEXCSQLIMMreply(Unknown Source)
> 	at org.apache.derby.client.net.NetStatementReply.readExecuteImmediate(Unknown Source)
> 	at org.apache.derby.client.net.StatementReply.readExecuteImmediate(Unknown Source)
> 	at org.apache.derby.client.net.NetStatement.readExecuteImmediate_(Unknown Source)
> 	at org.apache.derby.client.am.Statement.readExecuteImmediate(Unknown Source)
> 	at org.apache.derby.client.am.Statement.flowExecute(Unknown Source)
> 	at org.apache.derby.client.am.Statement.executeX(Unknown Source)
> 	... 26 more
> Unfortunately, when this happens, there seems to be no 'fail' directory created. The
derby.log in the system directory looks very innocent (just some start up and shutting down
of the database), and the serverConsoleOutput.log only has the typical 'failed to find db
'wombat' messages'.
> Note, when this happens, the suite exits, so that instead of the expected 20 (or 21 on
windows, see DERBY-5624 for reason for skipping on Linux default installs with 1024 max open
files) we only get 15 (or 16) tests run - if the test doesn't fail it goes on to run the last
5 fixtures again for network server.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message