You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by Marc von Holzen <ma...@vonholzen.org> on 2013/05/02 02:06:33 UTC
InternalErrorException: Unknown type: 0 -- corrupt database?
I'm using Fuseki 0.2.5. Received a series of stack traces below:
16:36:39 DEBUG TDB :: Txn[9622]/R: begin$
16:36:39 DEBUG TDB :: Txn[9622]/R: start
16:36:39 INFO Fuseki :: [9729] OK/select
16:36:39 DEBUG TDB :: Txn[9622]/R: finish
16:36:39 DEBUG TDB :: Txn[9622]/R: Start flush delayed
commits
16:36:39 DEBUG TDB :: Txn[9622]/R: Flush delayed commit
of Txn[8549]/W
16:36:39 DEBUG TDB :: Txn[9622]/R: Flush delayed commit
of Txn[8550]/W
16:36:39 DEBUG TDB :: Txn[9622]/R: Flush delayed commit
of Txn[8551]/W
16:36:39 DEBUG TDB :: Txn[9622]/R: Flush delayed commit
of Txn[8552]/W
16:36:39 DEBUG TDB :: Txn[9622]/R: Flush delayed commit
of Txn[8553]/W
16:36:39 DEBUG TDB :: Txn[9622]/R: Flush delayed commit
of Txn[8554]/W
16:36:39 DEBUG TDB :: Txn[9622]/R: Flush delayed commit
of Txn[8555]/W
16:36:39 DEBUG TDB :: Txn[9622]/R: Flush delayed commit
of Txn[8556]/W
16:36:39 DEBUG TDB :: Txn[9622]/R: Flush delayed commit
of Txn[9620]/W
16:36:39 DEBUG TDB :: Txn[9622]/R: Flush delayed commit
of Txn[9621]/W
16:36:40 ERROR JournalEntryType :: Unknown type: 0
16:36:41 ERROR TDB :: Exception during journal replay
org.openjena.atlas.lib.InternalErrorException: Unknown type: 0
at
com.hp.hpl.jena.tdb.transaction.JournalEntryType.type(JournalEntryType.java:43)
at com.hp.hpl.jena.tdb.transaction.Journal._read(Journal.java:228)
at
com.hp.hpl.jena.tdb.transaction.Journal._readJournal(Journal.java:197)
at
com.hp.hpl.jena.tdb.transaction.Journal.access$100(Journal.java:48)
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:248)
at
org.openjena.atlas.iterator.IteratorSlotted.hasNext(IteratorSlotted.java:67)
at
com.hp.hpl.jena.tdb.transaction.JournalControl.replay(JournalControl.java:245)
at
com.hp.hpl.jena.tdb.transaction.JournalControl.replay(JournalControl.java:232)
at
com.hp.hpl.jena.tdb.transaction.TransactionManager.processDelayedReplayQueue(TransactionManager.java:558)
at
com.hp.hpl.jena.tdb.transaction.TransactionManager.readerFinishesWorker(TransactionManager.java:466)
at
com.hp.hpl.jena.tdb.transaction.TransactionManager.access$300(TransactionManager.java:47)
16:36:42 WARN TDB :: Exception after commit point :
transaction commited but internal status not recorded properly
org.openjena.atlas.lib.InternalErrorException: Unknown type: 0
16:36:42 WARN Fuseki :: [9729] RC = 500 : Exc eption after
commit point - transaction did commit
com.hp.hpl.jena.tdb.transaction.TDBTransactionException: Exc eption after
commit point - transaction did commit
Caused by: org.openjena.atlas.lib.InternalErrorException: Unknown type: 0
at
com.hp.hpl.jena.tdb.transaction.JournalEntryType.type(JournalEntryType.java:43)
at com.hp.hpl.jena.tdb.transaction.Journal._read(Journal.java:228)
at
com.hp.hpl.jena.tdb.transaction.Journal._readJournal(Journal.java:197)
Opening the TDB now produces:
$ tdbstats --loc=private
16:54:13 ERROR JournalEntryType :: Unknown type: 0
Exception in thread "main"
org.apache.jena.atlas.lib.InternalErrorException: Unknown type: 0
at
com.hp.hpl.jena.tdb.transaction.JournalEntryType.type(JournalEntryType.java:43)
at com.hp.hpl.jena.tdb.transaction.Journal._read(Journal.java:228)
at com.hp.hpl.jena.tdb.transaction.Journal._readJournal(Journal.java:197)
at com.hp.hpl.jena.tdb.transaction.Journal.access$100(Journal.java:48)
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:248)
at
org.apache.jena.atlas.iterator.IteratorSlotted.hasNext(IteratorSlotted.java:67)
at
com.hp.hpl.jena.tdb.transaction.JournalControl.scanForCommit(JournalControl.java:156)
at
com.hp.hpl.jena.tdb.transaction.JournalControl.recoverFromJournal(JournalControl.java:134)
at
com.hp.hpl.jena.tdb.StoreConnection._makeAndCache(StoreConnection.java:238)
at com.hp.hpl.jena.tdb.StoreConnection.make(StoreConnection.java:218)
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)
at tdb.cmdline.ModTDBDataset.createDataset(ModTDBDataset.java:104)
at arq.cmdline.ModDataset.getDataset(ModDataset.java:34)
at tdb.cmdline.CmdTDBGraph.getGraph(CmdTDBGraph.java:68)
at tdb.tdbstats.exec(tdbstats.java:52)
at arq.cmdline.CmdMain.mainMethod(CmdMain.java:101)
at arq.cmdline.CmdMain.mainRun(CmdMain.java:63)
at arq.cmdline.CmdMain.mainRun(CmdMain.java:50)
at tdb.tdbstats.main(tdbstats.java:35)
Is there anyway to recover the data? Any help would be appreciated. I'd
be happy to help uncover why this happened in the first place, unless it's
a known bug.
Thanks
Marc
--
Marc von Holzen
(206) 383 7672
http://vonholzen.org/marc
Re: InternalErrorException: Unknown type: 0 -- corrupt database?
Posted by Andy Seaborne <an...@apache.org>.
On 02/05/13 14:21, Andy Seaborne wrote:
> I think this is a fixed problem; it may be in 0.2.6 else try
> 0.2.7-SNAPHSOT which is approaching a release.
It didn't make 0.2.6 if the root cause is what I'm guessing it is. What
were the operations up to this crash point?
Andy
Re: InternalErrorException: Unknown type: 0 -- corrupt database?
Posted by Andy Seaborne <an...@apache.org>.
On 02/05/13 18:17, Marc von Holzen wrote:
> Hi Andy,
>
> Thank you so much for your quick response. I successfully recovered the
> data. I will definitely upgrade to the latest.
>
> Regarding understanding the circumstances, my application interacts
> entirely via Fuseki services. Nothing more than a series of queries and
> updates. The logs don't show much. The only slightly unusual thing
> might be a few of "INSERT DATA {<> <> <>}" but they seem to have worked
> fine in the past.
>
> Thanks for your work,
> Marc
One of the problems with the 0.2.5 codebase was that any problem in a
section of the commit process caused the same symptom.
I looked at the svn history and found a possible reason a server with
multiple overlapping operations might break and cause the problem your
seeing. The fix did not make the last release - it is in the current
development snapshot builds.
I doubt "INSERT DATA {<> <> <>}" is related - more likely is two
transactions at the same time in a race-condition trying to flush the
journal. These can be read transactions - a read transaction can cause
the journal to be written back if a queue of pending commits has built
up and the read transaction is the last block on flushing the
write-ahead log. There was a bug (a small timing hole) here.
Glad you managed to recover the data,
Andy
Re: InternalErrorException: Unknown type: 0 -- corrupt database?
Posted by Marc von Holzen <ma...@vonholzen.org>.
Hi Andy,
Thank you so much for your quick response. I successfully recovered the
data. I will definitely upgrade to the latest.
Regarding understanding the circumstances, my application interacts
entirely via Fuseki services. Nothing more than a series of queries and
updates. The logs don't show much. The only slightly unusual thing might
be a few of "INSERT DATA {<> <> <>}" but they seem to have worked fine in
the past.
Thanks for your work,
Marc
On Thu, May 2, 2013 at 6:21 AM, Andy Seaborne <an...@apache.org> wrote:
> On 02/05/13 01:06, Marc von Holzen wrote:
>
>> I'm using Fuseki 0.2.5. Received a series of stack traces below:
>>
>
> Hi there,
>
> I think this is a fixed problem; it may be in 0.2.6 else try
> 0.2.7-SNAPHSOT which is approaching a release. I'd be interested in know
> what the circumstances are that caused this - this is recording a symptom
> of a problem but there are some points in the code where symptoms arise but
> may causes lead to the same symptom.
>
> You may be able to recover the database by deleting the journal files
> (*.jrnl). Then the database will not try to replay what's in the journal.
> You should get a consistent database (only whole transactions committed)
> but whether the last transaction was properly committed or not isn't clear.
> When I have seen this before the last write did not get commited properly
> (despite the log messages).
>
> I would advise dumping the database and rebuilding it.
>
> Andy
>
>
>
>> 16:36:39 DEBUG TDB :: Txn[9622]/R: begin$
>> 16:36:39 DEBUG TDB :: Txn[9622]/R: start
>> 16:36:39 INFO Fuseki :: [9729] OK/select
>> 16:36:39 DEBUG TDB :: Txn[9622]/R: finish
>> 16:36:39 DEBUG TDB :: Txn[9622]/R: Start flush delayed
>> commits
>> 16:36:39 DEBUG TDB :: Txn[9622]/R: Flush delayed commit
>> of Txn[8549]/W
>> 16:36:39 DEBUG TDB :: Txn[9622]/R: Flush delayed commit
>> of Txn[8550]/W
>> 16:36:39 DEBUG TDB :: Txn[9622]/R: Flush delayed commit
>> of Txn[8551]/W
>> 16:36:39 DEBUG TDB :: Txn[9622]/R: Flush delayed commit
>> of Txn[8552]/W
>> 16:36:39 DEBUG TDB :: Txn[9622]/R: Flush delayed commit
>> of Txn[8553]/W
>> 16:36:39 DEBUG TDB :: Txn[9622]/R: Flush delayed commit
>> of Txn[8554]/W
>> 16:36:39 DEBUG TDB :: Txn[9622]/R: Flush delayed commit
>> of Txn[8555]/W
>> 16:36:39 DEBUG TDB :: Txn[9622]/R: Flush delayed commit
>> of Txn[8556]/W
>> 16:36:39 DEBUG TDB :: Txn[9622]/R: Flush delayed commit
>> of Txn[9620]/W
>> 16:36:39 DEBUG TDB :: Txn[9622]/R: Flush delayed commit
>> of Txn[9621]/W
>> 16:36:40 ERROR JournalEntryType :: Unknown type: 0
>> 16:36:41 ERROR TDB :: Exception during journal replay
>> org.openjena.atlas.lib.**InternalErrorException: Unknown type: 0
>> at
>> com.hp.hpl.jena.tdb.**transaction.JournalEntryType.**
>> type(JournalEntryType.java:43)
>> at com.hp.hpl.jena.tdb.**transaction.Journal._read(**
>> Journal.java:228)
>> at
>> com.hp.hpl.jena.tdb.**transaction.Journal._**
>> readJournal(Journal.java:197)
>> at
>> com.hp.hpl.jena.tdb.**transaction.Journal.access$**100(Journal.java:48)
>> 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:248)
>> at
>> org.openjena.atlas.iterator.**IteratorSlotted.hasNext(**
>> IteratorSlotted.java:67)
>> at
>> com.hp.hpl.jena.tdb.**transaction.JournalControl.**
>> replay(JournalControl.java:**245)
>> at
>> com.hp.hpl.jena.tdb.**transaction.JournalControl.**
>> replay(JournalControl.java:**232)
>> at
>> com.hp.hpl.jena.tdb.**transaction.**TransactionManager.**
>> processDelayedReplayQueue(**TransactionManager.java:558)
>> at
>> com.hp.hpl.jena.tdb.**transaction.**TransactionManager.**
>> readerFinishesWorker(**TransactionManager.java:466)
>> at
>> com.hp.hpl.jena.tdb.**transaction.**TransactionManager.access$300(**
>> TransactionManager.java:47)
>>
>>
>> 16:36:42 WARN TDB :: Exception after commit point :
>> transaction commited but internal status not recorded properly
>> org.openjena.atlas.lib.**InternalErrorException: Unknown type: 0
>>
>> 16:36:42 WARN Fuseki :: [9729] RC = 500 : Exc eption after
>> commit point - transaction did commit
>> com.hp.hpl.jena.tdb.**transaction.**TDBTransactionException: Exc eption
>> after
>> commit point - transaction did commit
>>
>> Caused by: org.openjena.atlas.lib.**InternalErrorException: Unknown
>> type: 0
>> at
>> com.hp.hpl.jena.tdb.**transaction.JournalEntryType.**
>> type(JournalEntryType.java:43)
>> at com.hp.hpl.jena.tdb.**transaction.Journal._read(**
>> Journal.java:228)
>> at
>> com.hp.hpl.jena.tdb.**transaction.Journal._**
>> readJournal(Journal.java:197)
>>
>>
>> Opening the TDB now produces:
>>
>> $ tdbstats --loc=private
>> 16:54:13 ERROR JournalEntryType :: Unknown type: 0
>> Exception in thread "main"
>> org.apache.jena.atlas.lib.**InternalErrorException: Unknown type: 0
>> at
>> com.hp.hpl.jena.tdb.**transaction.JournalEntryType.**
>> type(JournalEntryType.java:43)
>> at com.hp.hpl.jena.tdb.**transaction.Journal._read(**Journal.java:228)
>> at com.hp.hpl.jena.tdb.**transaction.Journal._**
>> readJournal(Journal.java:197)
>> at com.hp.hpl.jena.tdb.**transaction.Journal.access$**
>> 100(Journal.java:48)
>> 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:248)
>> at
>> org.apache.jena.atlas.**iterator.IteratorSlotted.**
>> hasNext(IteratorSlotted.java:**67)
>> at
>> com.hp.hpl.jena.tdb.**transaction.JournalControl.**
>> scanForCommit(JournalControl.**java:156)
>> at
>> com.hp.hpl.jena.tdb.**transaction.JournalControl.**recoverFromJournal(**
>> JournalControl.java:134)
>> at
>> com.hp.hpl.jena.tdb.**StoreConnection._makeAndCache(**
>> StoreConnection.java:238)
>> at com.hp.hpl.jena.tdb.**StoreConnection.make(**StoreConnection.java:218)
>> 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)
>> at tdb.cmdline.ModTDBDataset.**createDataset(ModTDBDataset.**java:104)
>> at arq.cmdline.ModDataset.**getDataset(ModDataset.java:34)
>> at tdb.cmdline.CmdTDBGraph.**getGraph(CmdTDBGraph.java:68)
>> at tdb.tdbstats.exec(tdbstats.**java:52)
>> at arq.cmdline.CmdMain.**mainMethod(CmdMain.java:101)
>> at arq.cmdline.CmdMain.mainRun(**CmdMain.java:63)
>> at arq.cmdline.CmdMain.mainRun(**CmdMain.java:50)
>> at tdb.tdbstats.main(tdbstats.**java:35)
>>
>> Is there anyway to recover the data? Any help would be appreciated. I'd
>> be happy to help uncover why this happened in the first place, unless it's
>> a known bug.
>>
>> Thanks
>> Marc
>>
>>
>
--
Marc von Holzen
(206) 383 7672
http://vonholzen.org/marc
Re: InternalErrorException: Unknown type: 0 -- corrupt database?
Posted by Andy Seaborne <an...@apache.org>.
On 02/05/13 01:06, Marc von Holzen wrote:
> I'm using Fuseki 0.2.5. Received a series of stack traces below:
Hi there,
I think this is a fixed problem; it may be in 0.2.6 else try
0.2.7-SNAPHSOT which is approaching a release. I'd be interested in
know what the circumstances are that caused this - this is recording a
symptom of a problem but there are some points in the code where
symptoms arise but may causes lead to the same symptom.
You may be able to recover the database by deleting the journal files
(*.jrnl). Then the database will not try to replay what's in the
journal. You should get a consistent database (only whole transactions
committed) but whether the last transaction was properly committed or
not isn't clear. When I have seen this before the last write did not
get commited properly (despite the log messages).
I would advise dumping the database and rebuilding it.
Andy
>
> 16:36:39 DEBUG TDB :: Txn[9622]/R: begin$
> 16:36:39 DEBUG TDB :: Txn[9622]/R: start
> 16:36:39 INFO Fuseki :: [9729] OK/select
> 16:36:39 DEBUG TDB :: Txn[9622]/R: finish
> 16:36:39 DEBUG TDB :: Txn[9622]/R: Start flush delayed
> commits
> 16:36:39 DEBUG TDB :: Txn[9622]/R: Flush delayed commit
> of Txn[8549]/W
> 16:36:39 DEBUG TDB :: Txn[9622]/R: Flush delayed commit
> of Txn[8550]/W
> 16:36:39 DEBUG TDB :: Txn[9622]/R: Flush delayed commit
> of Txn[8551]/W
> 16:36:39 DEBUG TDB :: Txn[9622]/R: Flush delayed commit
> of Txn[8552]/W
> 16:36:39 DEBUG TDB :: Txn[9622]/R: Flush delayed commit
> of Txn[8553]/W
> 16:36:39 DEBUG TDB :: Txn[9622]/R: Flush delayed commit
> of Txn[8554]/W
> 16:36:39 DEBUG TDB :: Txn[9622]/R: Flush delayed commit
> of Txn[8555]/W
> 16:36:39 DEBUG TDB :: Txn[9622]/R: Flush delayed commit
> of Txn[8556]/W
> 16:36:39 DEBUG TDB :: Txn[9622]/R: Flush delayed commit
> of Txn[9620]/W
> 16:36:39 DEBUG TDB :: Txn[9622]/R: Flush delayed commit
> of Txn[9621]/W
> 16:36:40 ERROR JournalEntryType :: Unknown type: 0
> 16:36:41 ERROR TDB :: Exception during journal replay
> org.openjena.atlas.lib.InternalErrorException: Unknown type: 0
> at
> com.hp.hpl.jena.tdb.transaction.JournalEntryType.type(JournalEntryType.java:43)
> at com.hp.hpl.jena.tdb.transaction.Journal._read(Journal.java:228)
> at
> com.hp.hpl.jena.tdb.transaction.Journal._readJournal(Journal.java:197)
> at
> com.hp.hpl.jena.tdb.transaction.Journal.access$100(Journal.java:48)
> 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:248)
> at
> org.openjena.atlas.iterator.IteratorSlotted.hasNext(IteratorSlotted.java:67)
> at
> com.hp.hpl.jena.tdb.transaction.JournalControl.replay(JournalControl.java:245)
> at
> com.hp.hpl.jena.tdb.transaction.JournalControl.replay(JournalControl.java:232)
> at
> com.hp.hpl.jena.tdb.transaction.TransactionManager.processDelayedReplayQueue(TransactionManager.java:558)
> at
> com.hp.hpl.jena.tdb.transaction.TransactionManager.readerFinishesWorker(TransactionManager.java:466)
> at
> com.hp.hpl.jena.tdb.transaction.TransactionManager.access$300(TransactionManager.java:47)
>
>
> 16:36:42 WARN TDB :: Exception after commit point :
> transaction commited but internal status not recorded properly
> org.openjena.atlas.lib.InternalErrorException: Unknown type: 0
>
> 16:36:42 WARN Fuseki :: [9729] RC = 500 : Exc eption after
> commit point - transaction did commit
> com.hp.hpl.jena.tdb.transaction.TDBTransactionException: Exc eption after
> commit point - transaction did commit
>
> Caused by: org.openjena.atlas.lib.InternalErrorException: Unknown type: 0
> at
> com.hp.hpl.jena.tdb.transaction.JournalEntryType.type(JournalEntryType.java:43)
> at com.hp.hpl.jena.tdb.transaction.Journal._read(Journal.java:228)
> at
> com.hp.hpl.jena.tdb.transaction.Journal._readJournal(Journal.java:197)
>
>
> Opening the TDB now produces:
>
> $ tdbstats --loc=private
> 16:54:13 ERROR JournalEntryType :: Unknown type: 0
> Exception in thread "main"
> org.apache.jena.atlas.lib.InternalErrorException: Unknown type: 0
> at
> com.hp.hpl.jena.tdb.transaction.JournalEntryType.type(JournalEntryType.java:43)
> at com.hp.hpl.jena.tdb.transaction.Journal._read(Journal.java:228)
> at com.hp.hpl.jena.tdb.transaction.Journal._readJournal(Journal.java:197)
> at com.hp.hpl.jena.tdb.transaction.Journal.access$100(Journal.java:48)
> 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:248)
> at
> org.apache.jena.atlas.iterator.IteratorSlotted.hasNext(IteratorSlotted.java:67)
> at
> com.hp.hpl.jena.tdb.transaction.JournalControl.scanForCommit(JournalControl.java:156)
> at
> com.hp.hpl.jena.tdb.transaction.JournalControl.recoverFromJournal(JournalControl.java:134)
> at
> com.hp.hpl.jena.tdb.StoreConnection._makeAndCache(StoreConnection.java:238)
> at com.hp.hpl.jena.tdb.StoreConnection.make(StoreConnection.java:218)
> 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)
> at tdb.cmdline.ModTDBDataset.createDataset(ModTDBDataset.java:104)
> at arq.cmdline.ModDataset.getDataset(ModDataset.java:34)
> at tdb.cmdline.CmdTDBGraph.getGraph(CmdTDBGraph.java:68)
> at tdb.tdbstats.exec(tdbstats.java:52)
> at arq.cmdline.CmdMain.mainMethod(CmdMain.java:101)
> at arq.cmdline.CmdMain.mainRun(CmdMain.java:63)
> at arq.cmdline.CmdMain.mainRun(CmdMain.java:50)
> at tdb.tdbstats.main(tdbstats.java:35)
>
> Is there anyway to recover the data? Any help would be appreciated. I'd
> be happy to help uncover why this happened in the first place, unless it's
> a known bug.
>
> Thanks
> Marc
>