[jira] [Comment Edited] (JENA-289) Respect query timeouts in TDB implementation

["Andy Seaborne (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JENA-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13480798#comment-13480798 ] 

Andy Seaborne edited comment on JENA-289 at 10/20/12 7:29 PM:
--------------------------------------------------------------

Would it be possible to attach a profiler to an execution of this query and see where the time is going? I don't think it is the same same situation as your original example of { ?a ?b ?c . ?c ?d ?e }.

It does not seem to get much, if any optimization, so it may be that the code doing naive joins is not checking the timeout situation when it should. However, the reason isn't immediately obvious just by looking at the code so it might be elsewhere.

                
      was (Author: andy.seaborne):
    Would it be possible to attach a profiler to an execution of this query and see where the time is going? I don't hink it is the same same situation as your original example of { ?a ?b ?c . ?c ?d ?e }.

It does not seem to get much, if any optimization, so it may be that the code doing naive joins is not checking the timeout situation when it should. However, the reason isn't immediately obvious just by looking at the code so it might be elsewhere.

                  
> Respect query timeouts in TDB implementation
> --------------------------------------------
>
>                 Key: JENA-289
>                 URL: https://issues.apache.org/jira/browse/JENA-289
>             Project: Apache Jena
>          Issue Type: Improvement
>          Components: TDB
>    Affects Versions: TDB 0.9.1
>            Reporter: Mark Buquor
>         Attachments: TestTimeout.java, TestTimeout.java
>
>
> In general use, we sometimes see queries throw QueryCancelledException several seconds/minutes after the expected timeout. This is acceptable to a degree, but it appears that there are cases where a rogue query could execute unmitigated. The attached testcase is an example of a query that will execute and consume CPU/heap until an OutOfMemoryError is thrown.
> Example: The following query with 10s timeouts executed for ~7 minutes before throwing an OOME.
> Aug 3, 2012 10:18:19 AM Executing query [limit=1,000 timeout1=10s timeout2=10s]: SELECT * WHERE { ?a ?b ?c . ?c ?d ?e }
> java.lang.OutOfMemoryError: GC overhead limit exceeded
>     at java.util.HashSet.<init>(HashSet.java:86)
>     at org.openjena.atlas.iterator.FilterUnique.<init>(FilterUnique.java:26)
>     at org.openjena.atlas.iterator.Iter.distinct(Iter.java:438)
>     at com.hp.hpl.jena.tdb.solver.StageMatchTuple.makeNextStage(StageMatchTuple.java:116)
>     at com.hp.hpl.jena.tdb.solver.StageMatchTuple.makeNextStage(StageMatchTuple.java:44)
>     at org.openjena.atlas.iterator.RepeatApplyIterator.hasNext(RepeatApplyIterator.java:49)
>     at org.openjena.atlas.iterator.Iter$4.hasNext(Iter.java:295)
>     at com.hp.hpl.jena.sparql.engine.iterator.QueryIterPlainWrapper.hasNextBinding(QueryIterPlainWrapper.java:54)
>     at com.hp.hpl.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:108)
>     at com.hp.hpl.jena.sparql.engine.iterator.QueryIterSlice.hasNextBinding(QueryIterSlice.java:76)
>     at com.hp.hpl.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:108)
>     at com.hp.hpl.jena.sparql.engine.iterator.QueryIteratorWrapper.hasNextBinding(QueryIteratorWrapper.java:40)
>     at com.hp.hpl.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:108)
>     at com.hp.hpl.jena.sparql.engine.iterator.QueryIteratorWrapper.hasNextBinding(QueryIteratorWrapper.java:40)
>     at com.hp.hpl.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:108)
>     at com.hp.hpl.jena.sparql.engine.iterator.QueryIteratorWrapper.hasNextBinding(QueryIteratorWrapper.java:40)
>     at com.hp.hpl.jena.sparql.engine.iterator.QueryIteratorBase.hasNext(QueryIteratorBase.java:108)
>     at com.hp.hpl.jena.sparql.engine.ResultSetStream.hasNext(ResultSetStream.java:72)
>     at com.hp.hpl.jena.sparql.resultset.ResultSetApply.apply(ResultSetApply.java:41)
>     at com.hp.hpl.jena.sparql.resultset.XMLOutput.format(XMLOutput.java:52)
>     at com.hp.hpl.jena.query.ResultSetFormatter.outputAsXML(ResultSetFormatter.java:482)
>     at com.hp.hpl.jena.query.ResultSetFormatter.outputAsXML(ResultSetFormatter.java:460)
>     at TestTimout.main(TestTimout.java:84)
> Aug 3, 2012 10:25:41 AM Finished

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira