db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sunitha Kambhampati <ksunitha...@gmail.com>
Subject [PATCH] change to derbynet/testSecMec.java test to fix failure on 131 vms.
Date Mon, 16 May 2005 23:53:29 GMT
This patch fixes derbynet/testSecMec.java  test failure on 131 vms.

Problem - with 131 vms, if server and client are in the same jvm, on a 
second get connection with create=true attribute in the url, there is a 
hang.

Basically,
-- the first getConnection works ok
-- but on the second getConnection, a SQLWarning needs to be generated  
to say that the database already exists and in this scenario, it seems 
like at the point where it is creating a SQLWarning , there is a 
deadlock. The call to SQLWarning constructor does not return. On doing a 
java core dump , the thread in question seems to be in a wait state 
(conditional wait).  Guess is it has to do with the driver manager lock

I will file a jira entry to track this issue but for the test in 
question, changes were made to not use create=true except for the first 
connection. 

-- ran this test for both DerbyClient and JCC driver on both 
corresponding versions 131,141 ,142 on both IBM and Sun jdks. Also 
tested it on sun jdk 1.5.0.
-- ran derbynetmats on jdk142 ok.
-- ran derbynetclientmats on ibm131 ok.

svn stat
M      
java\testing\org\apache\derbyTesting\functionTests\tests\derbynet\testSecMec.java
M      
java\testing\org\apache\derbyTesting\functionTests\master\DerbyNet\testSecMec.out
M      
java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\testSecMec.out

If it looks ok, can a committer please commit these test changes.

Thanks,
Sunitha.

Mime
View raw message