[
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
