db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (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 22:05:59 GMT
     [ http://issues.apache.org/jira/browse/DERBY-1173?page=all ]

Mike Matrigali updated DERBY-1173:
----------------------------------


I took a look at the info that kathy has posted.  Here is what I found:

1) The stack traces from the hang look interesting, it would be good if someone more familar
with this specific 
      output could take a look.  Of most interest  is the derby lock trace in the finalizer
portion - is this normal?:
"Finalizer" daemon prio=9 tid=0x0093c0e8 nid=0xcd4 in Object.wait() [1816f000..1
816fd88]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x104fcb70> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:111)
        - locked <0x104fcb70> (a java.lang.ref.ReferenceQueue$Lock)
        at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127)
        at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
[1948f000..1948fd88]
        at java.lang.Object.wait(Native Method)
        - waiting on <0x10024d08> (a org.apache.derby.impl.services.locks.Active
Lock)
        at org.apache.derby.impl.services.locks.ActiveLock.waitForGrant(ActiveLo
ck.java:119)
        - locked <0x10024d08> (a org.apache.derby.impl.services.locks.ActiveLock
)
        at org.apache.derby.impl.services.locks.LockSet.lockObject(LockSet.java:
284)
        at org.apache.derby.impl.services.locks.SinglePool.zeroDurationlockObjec
t(SinglePool.java:458)
        at org.apache.derby.impl.store.raw.xact.RowLocking2nohold.lockRecordForR
ead(RowLocking2nohold.java:89)
        at org.apache.derby.impl.store.access.conglomerate.OpenConglomerate.lock
PositionForRead(OpenConglomerate.java:440)
        at org.apache.derby.impl.store.access.conglomerate.GenericScanController
.fetchRows(GenericScanController.java:691)
        at org.apache.derby.impl.store.access.heap.HeapScan.fetchNextGroup(HeapS
can.java:337)
        at org.apache.derby.impl.sql.execute.BulkTableScanResultSet.reloadArray(
BulkTableScanResultSet.java:330)
        at org.apache.derby.impl.sql.execute.BulkTableScanResultSet.getNextRowCo
re(BulkTableScanResultSet.java:285)
        at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.getNextRow(
BasicNoPutResultSetImpl.java:474)
        at org.apache.derby.impl.jdbc.EmbedResultSet.movePosition(EmbedResultSet
.java:409)
        - locked <0x10019c28> (a org.apache.derby.impl.jdbc.EmbedConnection30)
        at org.apache.derby.impl.jdbc.EmbedResultSet.next(EmbedResultSet.java:35
4)
        at org.apache.derby.impl.drda.DRDAConnThread.writeFDODTA(DRDAConnThread.
java:6142)



2) I  tried to connect the database in rerun part of the zip, and verified with kathy that
this zip represents the state at that
     point.  I could not connect at all to the database.  There are MANY files missing between
the initial zip and the rerun 
      zip file, including the database file associated with container 129 in the error message.
 And also missing are more
      than half of the actual database files, including many initial system catalog files
that Derby will just never delete.

      My view of what is going on is that the test harness in step 4 tried to "cleanup" the
environment before running, this
       cleanup included trying to delete the database.  It couldn't delete all the files as
the network server was still up and
      probably  still had a number of files still open which on windows would prevent their
deletion.  So it just left a mess
      of a database, which still could sort of be connected to in the running network server
- until attempt to access some
      file that had been deleted like c81.dat which is container 129.

      Could someone with expertise in the test harness comment of if this is likely consequence
of the steps kathy describes
       in the repro?

>  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: 10.0.2.1
>     Reporter: Kathey Marsden
>     Priority: Critical
>      Fix For: 10.2.0.0
>  Attachments: first_run_testfiles_afterhang.zip, rerun_test_files_with_corrupt_db.zip,
traces_on_hang.txt
>
> I am changing the description of this bug because I have a clearer reproducible case
for it and the old description has some information that is probably not relevant.
> If jdbcapi/checkDataSource30.java is aborted at a certain point in the test and then
rerun with the server still running, it will give a conglomerate not found error and the database
will be corrupted. 
> To Reproduce:
> 1)  Enable checkDataSource30.java by taking it out of functionTests/suites/DerbyNetClient.exclude.
> 2) Run the test with client.
> java -Dij.exceptionTrace=true -Dkeepfiles=true -Dframework=DerbyNetClient org.apache.derbyTesting.functionTests.harness.RunTest
jdbcapi/checkDataSource30.java
> 3) In a separate window,  tail the test output until you see the line:
> "DriverManager  <closedstmt>.execute() null - Invalid operation: statement close"
> e.g.
>   tail -f derbynetclient/checkDataSource30.tmp
> auto commit     true
>   read only       false
> setTypeMap(EMPTY_MAP) - FAIL 0A000 - Feature not implemented: setTypeMap.
> setTypeMap(null) - ok 0A000 - Feature not implemented: setTypeMap.
> setTypeMap(map) - ok 0A000 - Feature not implemented: setTypeMap.
> method calls on a closed connection
> DriverManager  <closedconn>.close() no error
> DriverManager  <closedconn>.createStatement() 08003 - No current connection.
> DriverManager  <closedstmt>.execute() null - Invalid operation: statement close
> 3) Abort the test run by pressing <ctrl> c
> 4) Rerun the test  without taking the server down
> java -Dij.exceptionTrace=true -Dkeepfiles=true -Dframework=DerbyNetClient org.apache.derbyTesting.functionTests.harness.RunTest
jdbcapi/checkDataSource30.java
> The following exception will occur on create table and the database will be corrupt.
> 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
starting
> 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 - 10.2.0.0 alpha shutdown at 2006-03-31 19:18:48.601 GMT
> Note: This tests hangs intermittently.  When it does, it always hangs at the point mentioned
in the reproduction for this issue.
> Some relevant history regarding the test hang:
> At revision 380672 I never saw the test hang
> At revision 390481 I noticed it had started hanging consistently.
> With the fix for DERBY-1144 the hang became intermittent.
> The hang happens more on jdk 1.5 and jdk 1.6.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message