You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Simon Helsen <sh...@ca.ibm.com> on 2012/08/29 17:05:02 UTC
journal recovery exception: any ideas?
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
Re: journal recovery exception: any ideas?
Posted by Simon Helsen <sh...@ca.ibm.com>.
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 <an...@apache.org>
To:
dev@jena.apache.org
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
>
Re: journal recovery exception: any ideas?
Posted by Andy Seaborne <an...@apache.org>.
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
>