[
https://issues.apache.org/jira/browse/JENA-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13452355#comment-13452355
]
Simon Helsen commented on JENA-289:
-----------------------------------
Incidentally, we hit this issue again with another client. They just observed
the OOME (They had 3,5Gb of data sitting in BindingTDB) and after deeper
analysis found that a query was doing something really bad which caused the
pathological explosion of the search space. Unlike the other client, they ran
into the OME before realizing the query was never aborted.
but here as well, once can fix the query to bypass the problem
> 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
