thanks for the response Andy. Since we do not use TDB as the primary storage, we are always in a position to "reindex" (i.e. push rdf resources in a regular databse into TDB). This process is expensive but allows to survive corruption.
My e-mail was more to find out if the problem was a) known and b) perhaps fixed later on. You answered that. However, note that in my attempt to recreate this problem I found a number of other possible exceptions when killing a tdb process. The details are in https://issues.apache.org/jira/browse/JENA-308 thanks Simon From: Andy Seaborne <[email protected]> To: [email protected] Date: 08/30/2012 05:06 AM Subject: Re: journal recovery exception: any ideas? See https://issues.apache.org/jira/browse/JENA-256?focusedCommentId=13418609&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13418609 Fixed r1369086 but you really want JENA-301 as well. You can try recovering the database, if nothing has touched it since the incident, by running the latest development build of TDB - all you need to do is to open the DB. tdbquery --loc=<pathToIndexRemoved> 'ASK{}' The setup process will replay the journal and it should be OK, icludin use with the released code. If the DB has been used without the journal, and there were writes, then the journalled committed transactions are lost. Do not reply the journal - the database is very likely to be corrupted that way. The DB is valid whether you replay the journal with dev code or not - it will have lost some state though if it has evolved without the journal being successfully played back. Andy On 29/08/12 16:05, Simon Helsen wrote: > Hi guys, > > we are testing with Jena 2.7.1 (transactional) in a customer deployment > (so, obviously, I don't have a test case from this) and we are seeing the > following on journal recovery: > > 2012-08-29 10:24:48,952 [ WebContainer : 8] WARN > com.ibm.team.jfs - Unhandled Exception > com.hp.hpl.jena.tdb.base.block.BlockException: BlockAccessBase: Bounds > exception: <pathToIndexRemoved>\GPOS.idn: (32798,32798) > at > com.hp.hpl.jena.tdb.base.file.BlockAccessBase.check(BlockAccessBase.java:107) > at > com.hp.hpl.jena.tdb.base.file.BlockAccessBase.check(BlockAccessBase.java:114) > at > com.hp.hpl.jena.tdb.base.file.BlockAccessDirect.write(BlockAccessDirect.java:85) > at > com.hp.hpl.jena.tdb.base.file.BlockAccessDirect.overwrite(BlockAccessDirect.java:104) > at > com.hp.hpl.jena.tdb.base.block.BlockMgrFileAccess.overwrite(BlockMgrFileAccess.java:102) > at > com.hp.hpl.jena.tdb.base.block.BlockMgrWrapper.overwrite(BlockMgrWrapper.java:89) > at > com.hp.hpl.jena.tdb.base.block.BlockMgrSync.overwrite(BlockMgrSync.java:90) > at > com.hp.hpl.jena.tdb.base.block.BlockMgrCache.overwrite(BlockMgrCache.java:206) > at > com.hp.hpl.jena.tdb.transaction.JournalControl.replay(JournalControl.java:305) > at > com.hp.hpl.jena.tdb.transaction.JournalControl.recoverSegment(JournalControl.java:175) > at > com.hp.hpl.jena.tdb.transaction.JournalControl.recoverFromJournal(JournalControl.java:128) > at > com.hp.hpl.jena.tdb.StoreConnection._makeAndCache(StoreConnection.java:231) > at > com.hp.hpl.jena.tdb.StoreConnection.make(StoreConnection.java:190) > at > com.hp.hpl.jena.tdb.transaction.DatasetGraphTransaction.<init>(DatasetGraphTransaction.java:63) > at > com.hp.hpl.jena.tdb.sys.TDBMakerTxn._create(TDBMakerTxn.java:49) > at > com.hp.hpl.jena.tdb.sys.TDBMakerTxn.createDatasetGraph(TDBMakerTxn.java:37) > 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) > > This is on a Windows 2008 Server machine. (64 bit, but as always > everything is run in direct mode) From the information I gathered, I am > pretty sure the issue surfaced after the client had killed the JVM. It is > unclear what activities exactly were going on when the kill was initiated, > but I am assuming it involved both read and write operations > > Is this stack trace known? Is it possible/likely something like this may > have been fixed in 2.7.4? > > thanks > > Simon > > PS: I will see if I can produce a test case by killing an async thread > which performed read/writes, but I am not too hopeful >
