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) conglomerate (129) requested does not exist error on create table after aborting and rerunning jdbcapi/checkDataSource test with client.
Date Mon, 10 Apr 2006 13:51:59 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1173?page=comments#action_12373851 ] 

Kathey Marsden commented on DERBY-1173:


Looking at the checkDataSource issues for jdk 1.5/jdk 1.6, I see that the hang and corruption
occur with the current codebase at revision 392930. This confirms that the problem still exists
even with the fix for DERBY-1144.  Also with jdk1.5 I was able to get it to reproduce with
the server started separately which is good.

I am attaching  the following files:
first_run_testfiles_afterhang.zip  - Test files and db after hang, but server is still up.
traces_on_hang.txt - Server stack traces on hang.
rerun_test_files_with_corrupt_db.zip - Test files after rerun with corrupt db.

I have disabled the checkDataSource30.java and checkDataSource.java tests for client since
it was failing often on jdk 1.5 and 1.6 with this hang.  I plan to do more work this week
to try to figure out what to exclude from the test to get it running reliably and put it back
in the suite (DERBY-435) , but don't plan any more diagnostic work on DERBY-1173.  


You can probably repro with the current codebase by:

1)  Enable checkDataSource30.java by taking it out of functionTests/suites/DerbyNetClient.exclude.

2) Run the test with client with jdk 1.5 or jdk 1.6. (jdk 1.6 failed more often in the nightlies).
I ran like this:
java -Dij.exceptionTrace=true -Dkeepfiles=true -Dframework=DerbyNetClient org.apache.derbyTesting.functionTests.harness.RunTest
(Note: the test will not always hang, but does so fairly often with these jvm's)


You can run the test with the server started separately by
    1) start the server.
       java org.apache.derby.drda.NetworkServerControl start 

     2) Run the test as above. Test will run against the server you started.

To get runtimeinfo run:
    java org.apache.derby.drda.NetworkServerControl runtimeinfo

To get lots of server debug on the console about commands the server received
    Set -Dderby.drda.debug=true


Q 1) what is the stack traces of the server threads when the "timeout/deadlock" happens. I
believe this is a single user, but
     multi-connection test.
A 1) See attached: traces_on_hang.txt

Q 2) are connections getting cleaned up on the server side after the control c of the client.
Note there are likely multiple
      connections in the client some of which are guaranteed not to have been active when
the client went away.
A 2)Runtimeinfo during the hang shows only one session which is for runtimeinfo itself.  The
test hangs just after checking methods on closed connections so it looks like all the client
connections are closed.  This session would be just for runtimeinfo itself.

Q 3) what is container 129 in this db. In a freshly created db it is the SYSTABLES_INDEX2
table. So it not existing is a
     serious issue. This has the feel of some lock/latch issue which has not been cleaned
up and then prevents subsequent
     access to the system.
A 3) I don't know how to tell that but attached file 'rerun_test_files_with_corrupt_db.zip'
has the test output with corrupt db.

Q 4) what does a lock table query return after reconnecting to the server? The repro is kill
the client, leave the server. Then
     reconnect to the existing server.

A 4)Reconnecting to the server while the test is hung shows no locks, so probably the assessment
that this is some sort of lock timeout situation was not correct.  

ij> select * from new org.apache.derby.diag.LockTable() as LT;
XID            |TYPE |MODE|TABLENAME                                                     
                                                                 |LOCKNAME            |STATE|TABLETYPE|LOCK&|I

0 rows selected


Dan mentioned some dubious code in  network server DRDAStatement.getPreparedStatement() in
DERBY-1025 with regard to BrokeredStatements and wonder if it might be related to this problem.
 I have not tried fixing that yet, just to see if it fixes the issue.

>  conglomerate (129) requested does not exist error on create table after aborting and
rerunning  jdbcapi/checkDataSource  test with client.
> -------------------------------------------------------------------------------------------------------------------------------------------
>          Key: DERBY-1173
>          URL: http://issues.apache.org/jira/browse/DERBY-1173
>      Project: Derby
>         Type: Bug

>   Components: Network Client, Store
>     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