Unfortunately the data is confidential. I can try to generate the same
errors on reseted db if same thing happens.
On 20/05/2021 14.10, Andy Seaborne wrote:
Please can we have a complete, minimal example.
On 19/05/2021 11:12, Mikael Pesonen wrote:
More info on this. When the causes of the two warnings are fixed,
same data is imported correctly and everything works.
So, when there are "too many" WARN level errors in importing data,
the graph becomes corrupted.
Unlikely to be related to how many.
You wrote:
>> but many warnings on invalid data
not two. What is the problem data?
Andy
On 18/05/2021 18.02, Andy Seaborne wrote:
On 18/05/2021 13:03, Mikael Pesonen wrote:
This occurred again on another server. There were no errors before
this, but many warnings on invalid data, if that is related. Now we
get this error on all operations.
12:57:42 WARN Fuseki :: [line: 149803, col: 81] Bad IRI:
<mailto:"Finskas> Code: 4/UNWISE_CHARACTER in PATH: The character
matches no grammar rules of URIs/IRIs. These characters are
permitted in RDF URI References, XML system identifiers, and XML
Schema anyURIs.
...
14:48:28 WARN Fuseki :: [line: 475806, col: 80] Lexical
form '' not valid for datatype XSD boolean
...
Most likely different issues - these are to do with your data (being
read in?).
They don't appear related but you could try a minimal test case
based on that data.
Another thing to investigate is to look at the earlier log entries
for [24] and see if you can spot the RDF terms that are affected by
comparing them to other incidents.
Maybe it is just one entry in the node table, or maybe not.
Andy
14:52:06 WARN Fuseki :: [24] RC = 500 : NodeTableTRDF/Read
org.apache.jena.tdb2.TDBException: NodeTableTRDF/Read
at
org.apache.jena.tdb2.store.nodetable.NodeTableTRDF.readNodeFromTable(NodeTableTRDF.java:87)
~[fuseki-server.jar:3.17.0]
at
org.apache.jena.tdb2.store.nodetable.NodeTableNative._retrieveNodeByNodeId(NodeTableNative.java:103)
~[fuseki-server.jar:3.17.0]
at
org.apache.jena.tdb2.store.nodetable.NodeTableNative.getNodeForNodeId(NodeTableNative.java:52)
~[fuseki-server.jar:3.17.0]
at
org.apache.jena.tdb2.store.nodetable.NodeTableCache._retrieveNodeByNodeId(NodeTableCache.java:206)
~[fuseki-server.jar:3.17.0]
at
org.apache.jena.tdb2.store.nodetable.NodeTableCache.getNodeForNodeId(NodeTableCache.java:131)
~[fuseki-server.jar:3.17.0]
at
org.apache.jena.tdb2.store.nodetable.NodeTableWrapper.getNodeForNodeId(NodeTableWrapper.java:52)
~[fuseki-server.jar:3.17.0]
at
org.apache.jena.tdb2.store.nodetable.NodeTableInline.getNodeForNodeId(NodeTableInline.java:65)
~[fuseki-server.jar:3.17.0]
at
org.apache.jena.tdb2.lib.TupleLib.quad(TupleLib.java:112)
~[fuseki-server.jar:3.17.0]
at
org.apache.jena.tdb2.lib.TupleLib.quad(TupleLib.java:108)
~[fuseki-server.jar:3.17.0]
at
org.apache.jena.tdb2.lib.TupleLib.lambda$convertToQuads$3(TupleLib.java:53)
~[fuseki-server.jar:3.17.0]
at
org.apache.jena.atlas.iterator.Iter$2.next(Iter.java:352)
~[fuseki-server.jar:3.17.0]
at
org.apache.jena.atlas.iterator.IteratorWrapper.next(IteratorWrapper.java:36)
~[fuseki-server.jar:3.17.0]
at
org.apache.jena.dboe.transaction.txn.IteratorTxnTracker.next(IteratorTxnTracker.java:39)
~[fuseki-server.jar:3.17.0]
at
org.apache.jena.atlas.iterator.Iter$2.next(Iter.java:352)
~[fuseki-server.jar:3.17.0]
at
org.apache.jena.atlas.iterator.Iter.next(Iter.java:1072)
~[fuseki-server.jar:3.17.0]
at
org.apache.jena.util.iterator.WrappedIterator.next(WrappedIterator.java:94)
~[fuseki-server.jar:3.17.0]
at
org.apache.jena.util.iterator.WrappedIterator.next(WrappedIterator.java:94)
~[fuseki-server.jar:3.17.0]
at
org.apache.jena.mem.TrackingTripleIterator.next(TrackingTripleIterator.java:47)
~[fuseki-server.jar:3.17.0]
at
org.apache.jena.mem.TrackingTripleIterator.next(TrackingTripleIterator.java:31)
~[fuseki-server.jar:3.17.0]
at
org.apache.jena.sparql.engine.iterator.QueryIterTriplePattern$TripleMapper.hasNextBinding(QueryIterTriplePattern.java:145)
~[fuseki-s erver.jar:3.17.0]
...
at
org.apache.jena.sparql.engine.ResultSetStream.hasNext(ResultSetStream.java:74)
~[fuseki-server.jar:3.17.0]
at
org.apache.jena.sparql.engine.ResultSetCheckCondition.hasNext(ResultSetCheckCondition.java:55)
~[fuseki-server.jar:3.17.0]
at
org.apache.jena.fuseki.servlets.SPARQLQueryProcessor.executeQuery(SPARQLQueryProcessor.java:324)
~[fuseki-server.jar:3.17.0]
at
...
Caused by: org.apache.thrift.protocol.TProtocolException:
Unrecognized type 0
at
org.apache.thrift.protocol.TProtocolUtil.skip(TProtocolUtil.java:144)
~[fuseki-server.jar:3.17.0]
at
org.apache.thrift.protocol.TProtocolUtil.skip(TProtocolUtil.java:60)
~[fuseki-server.jar:3.17.0]
at
org.apache.jena.riot.thrift.wire.RDF_Term.standardSchemeReadValue(RDF_Term.java:433)
~[fuseki-server.jar:3.17.0]
at
org.apache.thrift.TUnion$TUnionStandardScheme.read(TUnion.java:224)
~[fuseki-server.jar:3.17.0]
at
org.apache.thrift.TUnion$TUnionStandardScheme.read(TUnion.java:213)
~[fuseki-server.jar:3.17.0]
at org.apache.thrift.TUnion.read(TUnion.java:138)
~[fuseki-server.jar:3.17.0]
at
org.apache.jena.tdb2.store.nodetable.NodeTableTRDF.readNodeFromTable(NodeTableTRDF.java:82)
~[fuseki-server.jar:3.17.0]
... 108 more
14:52:06 INFO Fuseki :: [24] 500 Server Error (12 ms)
On 27/04/2021 13.22, Andy Seaborne wrote:
On 27/04/2021 09:59, Mikael Pesonen wrote:
That's our guess too, but would be nice to have some idea where
to look for the cause. Does Jena/Fuseki handle disk full
situations without corruption?
It should do (the transaction aborts) which is why I was asking.
Bulk loading, other than loader "basic" which is safe - depends
exactly when it happens in the process i.e. no guarantees.
Andy
On 27/04/2021 11.56, Andy Seaborne wrote:
In the original message,
There was shortage of disk space, hope the db is not corrupted.
What happened?
This is the only thing you've mentioned that relates to update.
Everything else is "read" and the fault occurred at an earlier
time or its an environmental factor (one mentioned file access
permissions e.g. another process is interfering with files).
Apr 12 12:30:55 solid java[22910]: [2021-04-12 12:30:55] Fuseki
WARN [346] RC = 500 : a fault occurred in a recent unsafe
memory access operation in compiled Java code Apr 12 12:30:55
solid java[22910]: at
org.apache.jena.dboe.base.buffer.RecordBuffer.compare(RecordBuffer.java:192)
~[fuseki-server.jar:3.17.0]
so JDK ByteBuffer.get failed bu works almost always. It is
likely to be an environmental factor (the file system,
background process messing around, hardware issue).
Andy
--
Lingsoft - 30 years of Leading Language Management
www.lingsoft.fi
Speech Applications - Language Management - Translation - Reader's and Writer's
Tools - Text Tools - E-books and M-books
Mikael Pesonen
System Engineer
e-mail: mikael.peso...@lingsoft.fi
Tel. +358 2 279 3300
Time zone: GMT+2
Helsinki Office
Eteläranta 10
FI-00130 Helsinki
FINLAND
Turku Office
Kauppiaskatu 5 A
FI-20100 Turku
FINLAND
