Re: NodeTableTRDF/Read exception
The only time I have seen anything similar to this is on Android where something other process is messing about the files. TDB is not proof again other processes accessing the same files, including with shared network drives where different computers access the same filesystem. Andy On 21/03/2022 11:39, Mikael Pesonen wrote: Got this again after few days of little usage after TDB2 was rebuilt from empty. Would you suggest this is hw error? No possibility that its Jena error? On 28/05/2021 17.25, Andy Seaborne wrote: On 28/05/2021 14:59, Mikael Pesonen wrote: I should try some older Jena/Fuseki version? Yes. Also - run on different hardware. - run multiple times - look at the data and see if anything unusual is in it. etc etc On 28/05/2021 16.49, Andy Seaborne wrote: On 28/05/2021 14:03, Mikael Pesonen wrote: No this is the fresh db, started from empty today. And plenty of disk space. So it's repeatble. With no Minimal, Verifiable, Complete Example, it'll have to be an on-site investigation. Try different versions. Andy On 28/05/2021 15.58, Andy Seaborne wrote: Why are you adding data to a broken database? On 28/05/2021 12:02, Mikael Pesonen wrote: Actually now it happened again. Same size, about 80MB of turtle, imported without warnings this time, but reading the graph fails with this exception. 13:59:39 WARN Fuseki :: [44] 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:113) ~[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-server.jar:3.17.0] at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114) ~[fuseki-server.jar:3.17.0] at org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.hasNextBinding(QueryIterRepeatApply.java:74) ~[fuseki-server.jar:3.17.0] at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114) ~[fuseki-server.jar:3.17.0] at org.apache.jena.sparql.engine.iterator.QueryIterBlockTriplesStar.hasNextBinding(QueryIterBlockTriplesStar.java:54) ~[fuseki-server.jar:3.17.0] at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114) ~[fuseki-server.jar:3.17.0] at org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.makeNextStage(QueryIterRepeatApply.java:101) ~[fuseki-server.jar:3.17.0] at org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.hasNextBinding(QueryIterRepeatApply.java:65) ~[fuseki-server.jar:3.17.0] at org.a
Re: NodeTableTRDF/Read exception
Got this again after few days of little usage after TDB2 was rebuilt from empty. Would you suggest this is hw error? No possibility that its Jena error? On 28/05/2021 17.25, Andy Seaborne wrote: On 28/05/2021 14:59, Mikael Pesonen wrote: I should try some older Jena/Fuseki version? Yes. Also - run on different hardware. - run multiple times - look at the data and see if anything unusual is in it. etc etc On 28/05/2021 16.49, Andy Seaborne wrote: On 28/05/2021 14:03, Mikael Pesonen wrote: No this is the fresh db, started from empty today. And plenty of disk space. So it's repeatble. With no Minimal, Verifiable, Complete Example, it'll have to be an on-site investigation. Try different versions. Andy On 28/05/2021 15.58, Andy Seaborne wrote: Why are you adding data to a broken database? On 28/05/2021 12:02, Mikael Pesonen wrote: Actually now it happened again. Same size, about 80MB of turtle, imported without warnings this time, but reading the graph fails with this exception. 13:59:39 WARN Fuseki :: [44] 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:113) ~[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-server.jar:3.17.0] at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114) ~[fuseki-server.jar:3.17.0] at org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.hasNextBinding(QueryIterRepeatApply.java:74) ~[fuseki-server.jar:3.17.0] at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114) ~[fuseki-server.jar:3.17.0] at org.apache.jena.sparql.engine.iterator.QueryIterBlockTriplesStar.hasNextBinding(QueryIterBlockTriplesStar.java:54) ~[fuseki-server.jar:3.17.0] at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114) ~[fuseki-server.jar:3.17.0] at org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.makeNextStage(QueryIterRepeatApply.java:101) ~[fuseki-server.jar:3.17.0] at org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.hasNextBinding(QueryIterRepeatApply.java:65) ~[fuseki-server.jar:3.17.0] at org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114) ~[fuseki-server.jar:3.17.0] at org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply.makeNextStage(QueryIterRepeatApply.java:101) ~[fuseki-server.jar:3.17.0] at org.apache.jena.sparql.engine.iterator.QueryIterRepeatApply
Re: fuseki-4.4.0: --file option forces read-only mode
Hi olivier,
No reason I can think of except being clear that updates to the file
will not be written back to the file.
Given the user has explicitly given "--update", allowing update seems
quite reasonable.
Recorded:
https://github.com/apache/jena/issues/1228
(we now have github issues enabled for the codebase - use JIRA or GH issues)
Andy
On 21/03/2022 02:41, Olivier Dameron wrote:
Hello,
When I run
${FUSEKI_HOME}/fuseki-server --file=someFile.ttl --update /dataset
the log displays:
INFO Server :: Dataset: in-memory: load file: someFile.ttl
INFO Server :: Running in read-only mode for /dataset
...
and indeed, update queries are not possible in spite of the --update
option:
INFO Fuseki :: [3] POST http://localhost:3030/dataset/update
INFO Fuseki :: [3] No Fuseki dispatch /dataset/update
Is it the normal behavior?
The --help option displays
--mem Create an in-memory, non-persistent dataset for the server
--file=FILE Create an in-memory, non-persistent dataset for the server,
initialised with the contents of the file
--update Allow updates (via SPARQL Update and SPARQL HTTP Update)
So I do not see any indication that --file should be read-only
Note that I managed to get the update working by
1. running the server with an empty dataset
${FUSEKI_HOME}/fuseki-server --mem --update /dataset
yes - not much point having a read-only empty dataset.
2. manually uploading someFile.ttl via the GUI
but doing things manually is cumbersome :-)
Thank you
olivier
