[
https://issues.apache.org/jira/browse/JENA-308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13445307#comment-13445307
]
Andy Seaborne commented on JENA-308:
------------------------------------
"BlockAccessBase: Bounds exception" -- already fixed.
"TDBTransactionException: Failed to read block checksum."
This is due to uncommited junk at the end of the main journal after a crash.
Fixed in svn.
"journalStartOffset not zero"
"TDBException: Different ids"
would be explained by failing to empty a file that was part-prepared. Fix
applied - not tested but I haven't managed to reproduce it anyway even after a
lot of runs.
Please open a new JIRA for this last point with a refined test case if the new
TDB code still exhibits it.
This test code locks up after many iterations, 230 or so in the debugger, 728
outside (possibly dead threads causing some kind of resource exhaustion)
> Index corruption after killing process
> --------------------------------------
>
> Key: JENA-308
> URL: https://issues.apache.org/jira/browse/JENA-308
> Project: Apache Jena
> Issue Type: Bug
> Components: TDB
> Affects Versions: TDB 0.9.1, TDB 0.9.4
> Environment: Windows 2008/7 (64 bit) both on IBM and SUN JVM 6.
> Direct mode
> Reporter: Simon Helsen
> Priority: Critical
> Fix For: TDB 0.9.4
>
> Attachments: journalRecoveryTest.zip
>
>
> We are faced with a series of possible exceptions which may or may not occur
> after an active tdb store is killed. The most common exception has the form:
> Exception in thread "Thread-3"
> com.hp.hpl.jena.tdb.transaction.TDBTransactionException: Feaild to read block
> checksum.
> at com.hp.hpl.jena.tdb.transaction.Journal._read(Journal.java:238)
> at
> com.hp.hpl.jena.tdb.transaction.Journal._readJournal(Journal.java:197)
> at com.hp.hpl.jena.tdb.transaction.Journal.access$1(Journal.java:192)
> at
> com.hp.hpl.jena.tdb.transaction.Journal$IteratorEntries.moveToNext(Journal.java:267)
> at
> com.hp.hpl.jena.tdb.transaction.Journal$IteratorEntries.moveToNext(Journal.java:1)
> at
> org.openjena.atlas.iterator.IteratorSlotted.hasNext(IteratorSlotted.java:67)
> at
> com.hp.hpl.jena.tdb.transaction.JournalControl.scanForCommit(JournalControl.java:148)
> at
> com.hp.hpl.jena.tdb.transaction.JournalControl.recoverFromJournal(JournalControl.java:127)
> at
> com.hp.hpl.jena.tdb.StoreConnection._makeAndCache(StoreConnection.java:234)
> at com.hp.hpl.jena.tdb.StoreConnection.make(StoreConnection.java:214)
> at
> com.hp.hpl.jena.tdb.transaction.DatasetGraphTransaction.<init>(DatasetGraphTransaction.java:76)
> at com.hp.hpl.jena.tdb.sys.TDBMaker._create(TDBMaker.java:57)
> at
> com.hp.hpl.jena.tdb.sys.TDBMaker.createDatasetGraphTransaction(TDBMaker.java:45)
> at
> com.hp.hpl.jena.tdb.TDBFactory._createDatasetGraph(TDBFactory.java:104)
> at com.hp.hpl.jena.tdb.TDBFactory.createDatasetGraph(TDBFactory.java:73)
> at com.hp.hpl.jena.tdb.TDBFactory.createDataset(TDBFactory.java:52)
> Other exceptions are possible (see comments below). I have been able to
> produce a standalone java program/test case which simulates a process kill
> and is able to produce the exception after a non-deterministic time. It runs
> an iteration until it hits one of the possible problems. Sometimes, an
> exception hits after just 2 iterations, other times, it can take 40 runs or
> more before hitting a problem. Because I don't know what the cause is here, I
> have not been able to make the test case more specific
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
