db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1173) Possible regression: jdbcapi/checkDataSource test hangs with client. After test is aborted, if rerun it gives he conglomerate (129) requested does not exist.
Date Thu, 06 Apr 2006 17:39:48 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1173?page=comments#action_12373522 ] 

Kathey Marsden commented on DERBY-1173:

Just some more clues for anyone who might be trying to get a better repro for this issue:

Likely the fix for DERBY-1144 changed the isolation level of  some of the test cases and caused
previous lock timeouts or deadlocks to not occur.  To get the checkDataSource30  test running
reliably. I set its derby properites to :

Without these set, I found that I did upon repeated runs get what appeared to be a hang but
perhaps was just a lock timeout.  Then I aborted  and rerun and got the conglomerate (129)
requested does not exist. error on create table.  (This was with the fix for DERBY-1144 in

So short story, there is probably   a good standalone repro that can be made for this issue,
by creating the deadlock or locktimeout scenario, but still probably the easiest first step
for anyone doing that would be to back out the fix for DERBY-1144 to see the issue and narrow
it down.

Also I no longer think this is a regression but probably started happenning because some other
locking behaviour or holdability changes that went in and caused the test to expose this issue.

> Possible regression: jdbcapi/checkDataSource test hangs with client. After test is aborted,
 if rerun it gives he conglomerate (129) requested does not exist.
> --------------------------------------------------------------------------------------------------------------------------------------------------------------
>          Key: DERBY-1173
>          URL: http://issues.apache.org/jira/browse/DERBY-1173
>      Project: Derby
>         Type: Bug

>   Components: JDBC, Network Client
>     Versions:
>     Reporter: Kathey Marsden
>     Priority: Critical
>      Fix For:

> I had been working on the checkDataSource test a few weeks ago, to get it working with
client but did not bring it into a suite at that time unfortunately.
> jdbcapi/checkDataSource.java now hangs with client.  If I abort the test with <ctrl>
c and rerun it fails on create table with:
>  Booting Derby version The Apache Software Foundation - Apache Derby - alpha
- (1): instance c013800d-010a-51bb-ae54-0000048a8d0f
> on database directory D:\testout4\DerbyNetClient\checkDataSource\wombat  
> Database Class Loader started - derby.database.classpath=''
> Could not listen on port 1527 on host localhost.
> 2006-03-31 19:18:47.370 GMT Thread[DRDAConnThread_6,5,main] (XID = 200), (SESSIONID =
1), (DATABASE = wombat), (DRDAID = NF000001.G90E-1097469790362120575{12}), Cleanup action
> 2006-03-31 19:18:47.370 GMT Thread[DRDAConnThread_6,5,main] (XID = 200), (SESSIONID =
1), (DATABASE = wombat), (DRDAID = NF000001.G90E-1097469790362120575{12}), Failed Statement
is: create table y(i int)
> ERROR XSAI2: The conglomerate (129) requested does not exist.
> 	at org.apache.derby.iapi.error.StandardException.newException(StandardException.java:311)
> 	at org.apache.derby.impl.store.access.btree.index.B2IFactory.readConglomerate(B2IFactory.java:241)
> 	at org.apache.derby.impl.store.access.RAMAccessManager.conglomCacheFind(RAMAccessManager.java:484)
> 	at org.apache.derby.impl.store.access.RAMTransaction.findExistingConglomerate(RAMTransaction.java:389)
> 	at org.apache.derby.impl.store.access.RAMTransaction.openConglomerate(RAMTransaction.java:1315)
> 	at org.apache.derby.impl.sql.catalog.TabInfoImpl.insertRowListImpl(TabInfoImpl.java:525)
> 	at org.apache.derby.impl.sql.catalog.TabInfoImpl.insertRow(TabInfoImpl.java:419)
> 	at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addDescriptorNow(DataDictionaryImpl.java:1637)
> 	at org.apache.derby.impl.sql.catalog.DataDictionaryImpl.addDescriptor(DataDictionaryImpl.java:1624)
> 	at org.apache.derby.impl.sql.execute.CreateTableConstantAction.executeConstantAction(CreateTableConstantAction.java:223)
> 	at org.apache.derby.impl.sql.execute.MiscResultSet.open(MiscResultSet.java:56)
> 	at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:361)
> 	at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1160)
> 	at org.apache.derby.impl.jdbc.EmbedStatement.execute(EmbedStatement.java:567)
> 	at org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(EmbedStatement.java:158)
> 	at org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLIMM(DRDAConnThread.java:4395)
> 	at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:645)
> 	at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:236)
> Cleanup action completed
> Apache Derby Network Server - alpha shutdown at 2006-03-31 19:18:48.601 GMT
> There is some relevant revison history:
> At r 380672   I made some changes to the test and the test passed with client
> At r 387611   I made some comment changes and accidently enabled one of the 
> failing client cases.
> At r 390481   I disabled the test for DERBY-1047 with client again, so the tests at 380672
(which passed) and the current test are the same.
> With the following patch for  DERBY-1144 the test does not normally hang.  I 
> don't know why and am a bit hesitant to check this patch in since it might be masking
something serious.
> Index: java/client/org/apache/derby/client/ClientPooledConnection.java
> ===================================================================
> --- java/client/org/apache/derby/client/ClientPooledConnection.java    (revision 
> 387603)
> +++ java/client/org/apache/derby/client/ClientPooledConnection.java    (working 
> copy)
> @@ -172,11 +172,14 @@
>              }
>              createLogicalConnection();
> +           
>              if (!newPC_) {
> -                physicalConnection_.reset(logWriter_, user_, password_, ds_, 
> false); // false means do not recompute
> +                // DERBY-1144 changed the last parameter of this method to true
> +                // to reset the connection state to the default on
> +                // PooledConnection.getConnection() otherwise the
> +                // isolation level was not correct and out of sync with the server.
> +                physicalConnection_.reset(logWriter_, user_, password_, ds_, true);
>              }
> -            // properties from the dataSource
> -            // properties don't change
>              else {
>                  physicalConnection_.lightReset();    //poolfix
>        }

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message