[
https://issues.apache.org/jira/browse/JENA-901?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14372471#comment-14372471
]
ASF GitHub Bot commented on JENA-901:
-------------------------------------
GitHub user stain opened a pull request:
https://github.com/apache/jena/pull/48
JENA-901 Use Guava for cache, shadowed in jena-core
In comparison with #47, this shadows Guava directly in `jena-core` without
introducing `jena-shadowed-ext`.
This is thus acceptable as a patch-version update - but at the downside
that `jena-core` have to do
import com.google.common.cache.Cache
directly - while all other Jena modules would have to use
import org.apache.jena.impl.ext.com.google.common.cache.Cache
as it is shadowed with the JAR. This will cause problems in the other
modules in an Eclipse-like environment, as the IDE will re-expose com.google
version if `jena-core` is open - and they would then seemingly not be able to
find the `oaj.impl.ext.*` version as that only exist in the Maven-built JAR.
In this scenario, it would probably be cleaner for the other modules to
also shadow guava - in addition to the space-wastage, this probably becomes a
bit awkward - it also means you can't pass any Guava structures between Jena
modules.
One advantage however is that if they all shadow individually, then they
can shadow with the
[minimizeJar](https://maven.apache.org/plugins/maven-shade-plugin/shade-mojo.html#minimizeJar)
option to only get the few Guava classes used (e.g. in jena-core only the
Cache).
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/stain/jena JENA-901-guava-only-jenacore
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/jena/pull/48.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #48
----
commit fa020df5320ec2aaaeec29aa568352bca5022347
Author: Stian Soiland-Reyes <[email protected]>
Date: 2015-03-21T02:51:28Z
JENA-901 Use Guava for cache, shadowed in jena-core
this avoids adding a new module, so this is acceptable
as a patch-version update.
----
> 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)
