One other question - is any of this docker or a VM, if so, what is the
filesystem setup?
Andy
On 16/04/18 13:43, Andy Seaborne wrote:
Hi Osma,
Could you send me the database? (zip the location, which should have the
pre-compacted database in it).
What changed just before queries started failing?
Do you happen to have the data used to build the database and the Fuseki
logs?
Andy
On 16/04/18 12:31, Osma Suominen wrote:
Hi,
We're setting up a new dev server using Fuseki2 3.7.0 and TDB2. We
have been loading some SKOS vocabularies (e.g. LCSH) into the store
via Fuseki (s-put). We created the database with a then current
3.7.0-SNAPSHOT on 2018-03-28 and switched to the final 3.7.0 soon
after it was released.
Today the database somehow got corrupted. SPARQL queries throw an
exception. We tried to use tdb2.tdbcompact, but it gave the same
exception. Traceback:
12:04:11 ERROR NodeTableTRDF :: Bad encoding: NodeId = [0x
1C1E78F3]
org.apache.jena.riot.thrift.RiotThriftException: No conversion to a
Node: <RDF_Term >
at
org.apache.jena.riot.thrift.ThriftConvert.convert(ThriftConvert.java:282)
at
org.apache.jena.riot.thrift.ThriftConvert.convert(ThriftConvert.java:209)
at
org.apache.jena.tdb2.store.nodetable.NodeTableTRDF.readNodeFromTable(NodeTableTRDF.java:81)
at
org.apache.jena.tdb2.store.nodetable.NodeTableNative._retrieveNodeByNodeId(NodeTableNative.java:103)
at
org.apache.jena.tdb2.store.nodetable.NodeTableNative.getNodeForNodeId(NodeTableNative.java:52)
at
org.apache.jena.tdb2.store.nodetable.NodeTableCache._retrieveNodeByNodeId(NodeTableCache.java:197)
at
org.apache.jena.tdb2.store.nodetable.NodeTableCache.getNodeForNodeId(NodeTableCache.java:108)
at
org.apache.jena.tdb2.store.nodetable.NodeTableWrapper.getNodeForNodeId(NodeTableWrapper.java:52)
at
org.apache.jena.tdb2.store.nodetable.NodeTableInline.getNodeForNodeId(NodeTableInline.java:66)
at org.apache.jena.tdb2.lib.TupleLib.quad(TupleLib.java:114)
at org.apache.jena.tdb2.lib.TupleLib.quad(TupleLib.java:110)
at
org.apache.jena.tdb2.lib.TupleLib.lambda$convertToQuads$3(TupleLib.java:53)
at org.apache.jena.atlas.iterator.Iter$2.next(Iter.java:270)
at
org.apache.jena.atlas.iterator.IteratorWrapper.next(IteratorWrapper.java:36)
at
org.apache.jena.tdb2.store.IteratorTxnTracker.next(IteratorTxnTracker.java:43)
at
java.util.Iterator.forEachRemaining(java.base@9-internal/Iterator.java:120)
at org.apache.jena.tdb2.sys.CopyDSG.lambda$null$0(CopyDSG.java:38)
at org.apache.jena.system.Txn.exec(Txn.java:81)
at org.apache.jena.system.Txn.executeWrite(Txn.java:133)
at org.apache.jena.tdb2.sys.CopyDSG.lambda$copy$1(CopyDSG.java:36)
at org.apache.jena.system.Txn.exec(Txn.java:81)
at org.apache.jena.system.Txn.executeRead(Txn.java:123)
at org.apache.jena.tdb2.sys.CopyDSG.copy(CopyDSG.java:35)
at
org.apache.jena.tdb2.sys.DatabaseOps.compact(DatabaseOps.java:235)
at
org.apache.jena.tdb2.sys.DatabaseOps.compact(DatabaseOps.java:201)
at tdb2.tdbcompact.exec(tdbcompact.java:44)
at jena.cmd.CmdMain.mainMethod(CmdMain.java:93)
at jena.cmd.CmdMain.mainRun(CmdMain.java:58)
at jena.cmd.CmdMain.mainRun(CmdMain.java:45)
at tdb2.tdbcompact.main(tdbcompact.java:28)
This is not (at least not yet) an important data store for us so at
the moment we just put the corrupdated database aside and created a
new one. But I thought I'd report the problem here in case someone
else has seen the same.
-Osma
