[
https://issues.apache.org/jira/browse/JENA-1376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16100733#comment-16100733
]
Andy Seaborne commented on JENA-1376:
-------------------------------------
A workaround: move the path expression to the end of the block.
{noformat}
where {
optional {
?b_args3_name gcc:strg ?b_args3_name_string.
?b_args3 gcc:name ?b_args3_name.
?b_args3 rdf:type gcc:parm_decl.
?b_args2 gcc:chain* ?b_args3.
}
{noformat}
This works for me when directly querying the data loaded into TDB.
What is happening is that the data is of unusual shape. There are very long
chains (5000 or more) of {{gcc:chain}} with one triple at each step of the
path. This isn't the design centre for the path engine which is more for more
fan-out and less depth. The implementation uses recursion (which is not a
tail-recursion). Rewiring the algorithm to detect this case (no fan-out) and
do it specially looks possible.
The optimizer does not reorder paths in this case. So the execution is as
written - do {{?b_args2 gcc:chain* ?b_args3}} first, not using the later
restrictions on {{?b_args3}}. The rewrite above calculates candidate
{{?b_args3}} first then tries each on the path. There are 9697 solutions to
this block.
The OPTIONAL is of no effect. It could be a fixed pattern.
The query does have two unconnected parts. Was a UNION intended? As written
it is a massive cross product.
The first part - the two optional blocks has 9697 solutions.
The second part - from after the two optional blocks, has 1060 solutions.
The first and second part are not connected by any variable. There are
9697*1060 = 10,278,820 solutions. ARQ streams so finding the first 10 distinct
is quite quick but is that what was meant by the query?
> FUSEKI recursive stack overflow crash on * query in optional where clause
> -------------------------------------------------------------------------
>
> Key: JENA-1376
> URL: https://issues.apache.org/jira/browse/JENA-1376
> Project: Apache Jena
> Issue Type: Bug
> Reporter: james michael dupont
>
> changing
> {noformat}
> ?b_args2 gcc:chain ?b_args3.
> {noformat}
> to
> {noformat}
> ?b_args2 gcc:chain* ?b_args3.
> {noformat}
> causes a 500 error see http://paste.debian.net/977429/ for the full stack.
> at
> org.apache.jena.sparql.path.eval.PathEngineSPARQL.ALP_1(PathEngineSPARQL.java:133)
> {noformat}
> prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
> PREFIX gcc:
> <https://h4ck3rm1k3.github.io/gogccintro/gcc/ontology/2017/05/20/gcc_compiler.owl#>
> PREFIX owl: <http://www.w3.org/2002/07/owl#>
> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
> select distinct
> ?b
> ?b_name_string
> ?b_args ?b_args_type ?b_args_name_string ?b_args2_name_string
> ?b_args3_name_string
> where {
>
> optional {
> ?b_args2 gcc:chain* ?b_args3.
> ?b_args3_name gcc:strg ?b_args3_name_string.
> ?b_args3 gcc:name ?b_args3_name.
> ?b_args3 rdf:type gcc:parm_decl.
> }
>
> optional {
> ?b_args gcc:chain ?b_args2.
> ?b_args2_name gcc:strg ?b_args2_name_string.
> ?b_args2 gcc:name ?b_args2_name.
> ?b_args2 rdf:type gcc:parm_decl.
> }
>
> ?b_args_name gcc:strg ?b_args_name_string.
> ?b_args gcc:name ?b_args_name.
> ?b_args rdf:type gcc:parm_decl.
>
> ?b rdf:type gcc:function_decl.
> ?b gcc:scpe ?a.
> ?b gcc:name ?b_name.
> ?b gcc:args ?b_args.
> ?b_name gcc:strg ?b_name_string.
> ?a rdf:type gcc:translation_unit_decl.
>
> }
> limit 10
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
