[
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
