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
