[ 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
