[
https://issues.apache.org/jira/browse/JENA-901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andy Seaborne updated JENA-901:
-------------------------------
Description:
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.
was:
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.
/** 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<>();
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.
SELECT ?p ?o
WHERE {
GRAPH ?g {
<some resource of interest> ?p ?o .
}
}
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.
> 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)
