Alex Kourijoki created JENA-1529:
------------------------------------
Summary: tdb2.tdbquery prints heavy stack trace whilst querying a
TDB2 store
Key: JENA-1529
URL: https://issues.apache.org/jira/browse/JENA-1529
Project: Apache Jena
Issue Type: Bug
Affects Versions: Jena 3.7.0
Environment: $ java -version
openjdk version "9-internal"
OpenJDK Runtime Environment (build 9-internal+0-2016-04-14-195246.buildd.src)
OpenJDK 64-Bit Server VM (build 9-internal+0-2016-04-14-195246.buildd.src,
mixed mode)
Ubuntu 16.04.04 LTS
Reporter: Alex Kourijoki
After upgrading Fuseki to 3.7.0 and switching from TDB1 to TDB2 I noticed that
Fuseki was busy generating colossal log files. Digging a bit deeper, I found
the root cause to be that this query
{code:java}
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
SELECT ?conc ?label ?lang
WHERE {
?conc a skos:Concept .
?conc skos:prefLabel ?label .
#BIND ("anything" as ?anything) # interestingly, uncommenting this line
prevents stack trace from appearing in tdb2
VALUES (?lang) { ('en') ('de') }
FILTER (langMatches(lang(?label), ?lang))
}
LIMIT 3
{code}
against this example .ttl file
{code:java}
@base <http://example.org/> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
<#example1> a skos:Concept ;
skos:prefLabel "test1 with 'en' langcode"@en,
"test1 with 'de' langcode"@de,
"test1 with no langcode" .
<#example2> a skos:Concept ;
skos:prefLabel "test2 with 'en' langcode"@en,
"test2 with 'de' langcode"@de,
"test2 with no langcode" .
{code}
generates the following kind of stack traces:
{code:java}
ERROR BindingTDB :: get1(?lang)
org.apache.jena.tdb2.TDBException: No node in NodeTable for NodeId
[DoesNotExist]
at org.apache.jena.tdb2.solver.BindingTDB.get1(BindingTDB.java:127)
at
org.apache.jena.sparql.engine.binding.BindingBase.get(BindingBase.java:104)
at org.apache.jena.sparql.expr.ExprVar.eval(ExprVar.java:60)
at org.apache.jena.sparql.expr.ExprVar.eval(ExprVar.java:53)
at org.apache.jena.sparql.expr.ExprNode.eval(ExprNode.java:93)
at org.apache.jena.sparql.expr.ExprFunction2.eval(ExprFunction2.java:77)
at org.apache.jena.sparql.expr.ExprNode.isSatisfied(ExprNode.java:41)
at
org.apache.jena.sparql.engine.iterator.QueryIterFilterExpr.accept(QueryIterFilterExpr.java:49)
at
org.apache.jena.sparql.engine.iterator.QueryIterProcessBinding.hasNextBinding(QueryIterProcessBinding.java:69)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
at
org.apache.jena.sparql.engine.iterator.QueryIterConvert.hasNextBinding(QueryIterConvert.java:58)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
at
org.apache.jena.sparql.engine.iterator.QueryIterSlice.hasNextBinding(QueryIterSlice.java:76)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorWrapper.hasNextBinding(QueryIteratorWrapper.java:39)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorWrapper.hasNextBinding(QueryIteratorWrapper.java:39)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorWrapper.hasNextBinding(QueryIteratorWrapper.java:39)
at
org.apache.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:114)
at
org.apache.jena.sparql.engine.ResultSetStream.hasNext(ResultSetStream.java:74)
at
org.apache.jena.sparql.engine.ResultSetCheckCondition.hasNext(ResultSetCheckCondition.java:55)
at
org.apache.jena.sparql.resultset.ResultSetMem.<init>(ResultSetMem.java:90)
at
org.apache.jena.query.ResultSetFactory.makeRewindable(ResultSetFactory.java:357)
at org.apache.jena.sparql.resultset.TextOutput.write(TextOutput.java:145)
at org.apache.jena.sparql.resultset.TextOutput.write(TextOutput.java:130)
at org.apache.jena.sparql.resultset.TextOutput.write(TextOutput.java:118)
at org.apache.jena.sparql.resultset.TextOutput.format(TextOutput.java:66)
at org.apache.jena.query.ResultSetFormatter.out(ResultSetFormatter.java:165)
at
org.apache.jena.sparql.util.QueryExecUtils.outputResultSet(QueryExecUtils.java:157)
at
org.apache.jena.sparql.util.QueryExecUtils.doSelectQuery(QueryExecUtils.java:191)
at
org.apache.jena.sparql.util.QueryExecUtils.executeQuery(QueryExecUtils.java:78)
at arq.query.lambda$queryExec$0(query.java:224)
at org.apache.jena.system.Txn.exec(Txn.java:81)
at org.apache.jena.system.Txn.executeRead(Txn.java:123)
at arq.query.queryExec(query.java:221)
at arq.query.exec(query.java:153)
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.tdbquery.main(tdbquery.java:30)
{code}
Finally, a correct answer is provided:
{code:java}
-------------------------------------------------------------------------
| conc | label | lang |
=========================================================================
| <http://example.org/#example1> | "test1 with 'en' langcode"@en | "en" |
| <http://example.org/#example2> | "test2 with 'en' langcode"@en | "en" |
| <http://example.org/#example1> | "test1 with 'de' langcode"@de | "de" |
-------------------------------------------------------------------------
{code}
This seemed not to happen with apache-jena-3.7.0/bin/tdbquery against a TDB1
store with the same query. Interestingly, having a bind of any kind in the
query seemed to resolve the issue for tdb2.tdbquery.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
