[jira] [Commented] (JENA-901) Make the cache of LPBRuleEngine bounded to avoid out-of-memory

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

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

ASF GitHub Bot commented on JENA-901:
-------------------------------------

Github user stain commented on the issue:

    https://github.com/apache/jena/pull/47
  
    OK, I've rebased for 3.1.1-SNAPSHOT, updated for Java 8 and fixed the System properties. 
    
    As for the `FIXME` comment let's just leave it here, unless someone understands or would be willing to investigate what is the semantic difference between the `LPInterpreter` constructor [without clauses](https://github.com/apache/jena/blob/master/jena-core/src/main/java/org/apache/jena/reasoner/rulesys/impl/LPInterpreter.java#L99) and [with clauses](https://github.com/apache/jena/blob/master/jena-core/src/main/java/org/apache/jena/reasoner/rulesys/impl/LPInterpreter.java#L111) (which could be [empty](https://github.com/apache/jena/blob/master/jena-core/src/main/java/org/apache/jena/reasoner/rulesys/impl/LPInterpreter.java#L130))  but then would not use `engine.getRuleStore().codeFor(goal)`.
    
    (Perhaps raise that as a new Jira issue?)


> Make the cache of LPBRuleEngine bounded to avoid out-of-memory
> --------------------------------------------------------------
>
>                 Key: JENA-901
>                 URL: https://issues.apache.org/jira/browse/JENA-901
>             Project: Apache Jena
>          Issue Type: Improvement
>          Components: Reasoners
>    Affects Versions: Jena 2.12.1
>            Reporter: Jan De Beer
>
> The class "com.hp.hpl.jena.reasoner.rulesys.impl.LPBRuleEngine" uses an in-memory cache named "tabledGoals", which has no limit as to the size/number of entries stored.
> {noformat}
>     /** Table mapping tabled goals to generators for those goals.
>      *  This is here so that partial goal state can be shared across multiple queries. */
>     protected HashMap<TriplePattern, Generator> tabledGoals = new HashMap<>();
> {noformat}
> We have experienced out-of-memory issues because of the cache being filled with millions of entries in just a few days under normal query usage conditions and a heap memory set to 3GB.
> In our setup, we have a dataset containing multiple graphs, some of them are actual data graphs (backed by TDB), and then there are two which are ontology models using a "TransitiveReasoner" and an "OWLMicroFBRuleReasoner", respectively. A typical query may run over all the graphs in the dataset, including the ontology ones (see below for a query template). Eventhough the ontology graphs would not yield any additional results for data queries (which is fine), the above mentioned cache would still fill up with new entries.
> {noformat}
> SELECT ?p ?o
> WHERE {
>   GRAPH ?g {
>     <some resource of interest> ?p ?o .
>   }
> }
> {noformat}
> As there is no upper bound to the cache, soon or later all available heap memory will be consumed by the cache, giving rise to an out-of-memory criticial error.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)