Re: NodeTableTRDF/Read exception

2021-05-27 Thread Andy Seaborne 
See the thread following from Harri's message "TDBException: 
NodeTableTRDF/Read (vol. 2)"


Andy


On 27/05/2021 15:56, Mikael Pesonen wrote:


Tried with the invalid data on fresh db and it didn't cause this 
exception. So root cause happened probably way earlier and is unknown.


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: 
 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

Re: NodeTableTRDF/Read exception

2021-05-27 Thread Mikael Pesonen 



Tried with the invalid data on fresh db and it didn't cause this 
exception. So root cause happened probably way earlier and is unknown.


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: 
 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

Re: Federated Query with credentials

2021-05-27 Thread Jens Zurawski 

Hi Andy,

thanks for your effort on trying to reproduce our case.

I'm using the binary package apache-jena-fuseki-4.0.0.tar.gz from 
https://jena.apache.org/download/index.cgi with open jdk 11. The 
configuration isn't altered much from the package defaults, mainly the 
shiro.ini config for securing the access.


The used query is pretty complex I don't want to bother you with this. 
So I will check again on my environment in order to get more detailed 
information and will try to create a simple reproduceable test case for you.


I will come back to this next week.
Jens


Am 27.05.2021 um 10:27 schrieb Andy Seaborne:

Jens -

When I tried to recreate this with 4.0.0 but I get "400 Bad request" 
not a 500 (and it works in development).


Which binary packaging are you using?
What is the server configuration?
What is the query with the SERVICE in it?
What does the log have in it for the request?

    Andy

On 26/05/2021 21:33, Andy Seaborne wrote:



On 26/05/2021 18:08, Jens Zurawski wrote:

Hi Andy, hi list,

...
Does that mean that in future versions the IRI method will work 
again but only put some warnings? Because 4.0.0 throws an HTTP 500 
error and no warning.


--
jens zurawski
diegurus - zurawski zurawski poppl rohland GbR
juister straße 3
65199 wiesbaden

kaspersweg 7b
26131 oldenburg

internet http://www.diegurus.de

tel +49(0)611 72437966


CONFIDENTIALITY NOTICE: This e-mail message is intended only for the
person or entity to which it is addressed and may contain confidential
and/or privileged material. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply e-mail and destroy all copies of the
original message.  If you are the intended recipient but do not wish to
receive communications through this medium, please so advise the sender
immediately.

Re: Federated Query with credentials

2021-05-27 Thread Andy Seaborne 

Jens -

When I tried to recreate this with 4.0.0 but I get "400 Bad request" not 
a 500 (and it works in development).


Which binary packaging are you using?
What is the server configuration?
What is the query with the SERVICE in it?
What does the log have in it for the request?

Andy

On 26/05/2021 21:33, Andy Seaborne wrote:



On 26/05/2021 18:08, Jens Zurawski wrote:

Hi Andy, hi list,

...
Does that mean that in future versions the IRI method will work again 
but only put some warnings? Because 4.0.0 throws an HTTP 500 error and 
no warning.