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, 15 Mar 2012 17:25:40 GMT

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

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

Hi Knut, I appreciate you taking the time to look at this. 

I have another alternative approach(which requires just one line change to large data suite
network server run) to fix the problem with intermittent lock time out issues possibly because
of background threads trying to finish post-commit changes related to large objects. 

The issue has been that the CleanDatabaseTestSetup , after the last test fixture of embedded
suite is done, tries to drop the tables but runs into lock timeout errors and hence it never
finishes dropping the tables. None of these errors get reported anywhere by CleanDatabaseTestSetup
and we simply move on to the next suite which in our case is network server running the large
data tests. As part of CleanDatabaseTestSetup decorator for network server, we try to drop
the existing objects in the database again before creating the new objects required by the
new suite and the drop tables again run into lock timeouts. 

What I am suggesting as a solution is to have the network server suite use a brand new database
to do it's testing via singleUseDatabaseDecorator and that way it will not run into locks
held on the database used by the embedded run of large data tests. The change is fairly easy(just
one line change) in LobLimitsClientTest.suite(). The changed LobLimitsClientTest,suite looks
as follows
    public static Test suite() {
        return TestConfiguration.singleUseDatabaseDecorator(
             TestConfiguration.clientServerDecorator(LobLimitsTest.suite()));
    }
The original LobLimitsClientTest,suite() in svn looks as follows
     public static Test suite() {
        return TestConfiguration.clientServerDecorator(LobLimitsTest.suite());
     }
 }


I ran the large data suite twice on my machine with this change and I don't see the lock timeout
from network server in the log file anymore. I will go ahead and commit this change.

Additionally, I will create a new jira for CleanDatabaseTestSetup about not reporting failures
while trying to clean the database by dropping the objects., Either, it should report those
errors in fail directory or somewhere else so we can diagnose more easily if the subsequent
suite fails because of left over database objects from the previous suite. Or it can try to
drop the objects as it does but if it can't drop them successfully, then it should drop the
database and create a brand new database which is clean for the next suite to use. One of
the things that CleanDatabaseTestSetup can do is what Knut suggested. Do TRUNCATE TABLE if
it is having trouble dropping the tables and then try to drop the tables again or wait for
post-commit to finish by calling T_Access.waitForPostCommitToFinish() before dropping objects
from the database.
                
> 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
>            Assignee: Mamta A. Satoor
>         Attachments: CompleteRunallWithPrintlnTrace.out, DERBY5638_patch1_diff.txt, DERBY5638_patch2_diff.txt,
derbyFailed.log, derbyPass.log, derbyWithRollbackInTest_05.log, derbyallFailWithPrintlnTrace.log,
runallForSuccessfulLargeDataRun.out, runallWithPrintlnTrace.out
>
>
> 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