This error occurs with all actions related to same graph. So I can't for example drop or clear the graph anymore.
Actions on other graphs work as usual.

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

Reply via email to