[
https://issues.apache.org/jira/browse/JENA-289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14157250#comment-14157250
]
Andy Seaborne commented on JENA-289:
------------------------------------
~kbkreddy,
Upgrading to newer version of Jena is the safest - the on-disk format of TDB
has not changed and you'll get the many other fixes and improvements. TDB 0.9.4
was released October 2012, so maybe Jena 2.10.0 (2.7.4 is followed by 2.10.0
where we aligned version numbers, it was not an architectural change). Of
course, current release is better still.
Otherwise, you could take the 0.9.4 source and recompile (the source-release
for Jena 2.7.4 or take the tag in svn for "jena-2.7.4") then check changes from
the time of the tag to svn revisoon 1425541.
> 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
> Assignee: Andy Seaborne
> Fix For: TDB 0.10.0
>
> 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 was sent by Atlassian JIRA
(v6.3.4#6332)
