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

Simon Helsen edited comment on JENA-289 at 9/27/12 5:48 AM:
------------------------------------------------------------

The main problem we face is that it may cause a production system to go on its 
knees. We recently had such an instance because of a mistake in how a query was 
written. Without a reliable abort we put ourselves at great risk. And I should 
add that during our testing efforst, we are encountering countless queries 
which run into this situation and refuse to abort. These queries can usually be 
fixed or rewritten, but it seems remarkably easy for our clients to produce 
such queries which require the server to be killed. The latter action then 
often causes corruptions because Jena 2.7.1 is not good at handling abrupt 
process kills. And since there is no 2.7.4 release with all these fixes...
                
      was (Author: shelsen):
    The main problem we face is that may cause a production system to go on its 
knees. We recently had such an instance because of a mistake in how a query was 
written. Without a reliable abort we put ourselves at great risk. 
                  
> 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
>            Priority: Critical
>         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

Reply via email to