+1 from this non-committer to holding the cache work for now. A simple on-off switch seems absolutely requisite, and preferably we would have fine-grained controls. The sudden appearance of an always-on cache like this would represent really surprising new behavior for integrators. Also, from the discussion on the PR in question [1] it seems to me that there are still some questions of design.
[1] https://github.com/apache/jena/pull/95 --- A. Soroka The University of Virginia Library > On Apr 29, 2016, at 12:38 PM, Andy Seaborne <[email protected]> wrote: > > I'd like to go ahead with 3.1.0. > > The work on a query cache for Fuseki [*] was tested by Osma and found to be > useful. There was also feedback on configuration and bounding the resources > consumed by the caches. Without the ability to configure it (including turn > it off) I don't think that putting it in right before a release is a good > idea. There are is still some discussion to be had about the detailed design > goals. > > So what I suggest is release Jena 3.1.0 now as-is, and start a > testing/evaluation phase for a configurable cache. > > As a cache is most important under load, and Fuseki is used in deployed and > public facing systems, I'm concerned that we block people picking up all the > other things in 3.1.0. I think it would be good to get wider testing via > users@. That will take time. (And then if people don't test it until after > its in a release ... well, we can only do our best.) > > Andy > > [*] > https://issues.apache.org/jira/browse/JENA-626 > https://github.com/apache/jena/pull/95 > > On 18/04/16 12:35, Osma Suominen wrote: >> Hi Andy! >> >> I'm happy with the current state of Jena and would support a release. >> This time I've been more diligent in using recent snapshots so there >> should be less chance of problems that surface only around release time. >> >> I have no outstanding work that I want to do for jena-text currently. >> JENA-1134/AnalyzingQueryParser (which you can consider including in the >> release notes) was the major item for me since the previous release, >> plus some bugfixes that were done earlier. >> >> -Osma >> >> On 18/04/16 13:44, Andy Seaborne wrote: >>> Version 3.1.0 has quite a few good things in it1 >>> >>> I think it is about time we released it. >>> >>> So this is a first ping for anything you want to get done for it. >>> >>> As for timing - I can RM it sometime in the next few weeks though it >>> will have to fit around other things. >>> >>> Andy >>> >>> ------------------------------------------- >>> >>> * New custom functions and aggregate functions >>> Added: >>> + afn:sprintf (contribution from Alessandro Seganti) >>> + The XQuery/XPath Functions and Operators "math:" functions >>> + Custom aggregates for stdev etc. (also STDEV etc as keywords). >>> >>> * RC features in 3.0.1: >>> + In-memory transactional dataset (Adam Soroka ) >>> + SPARQL extension for CONSTRUCT Quads (Qihong Lin) >>> >>> * OSGi fixes (Jaroslav Pullmann) >>> >>> * Upgrades: >>> jsonld-java : 2.8.2 >>> jackson 2.6.3 >>> slf4j 1.7.20 >>> dexx collections 0.2 -> 0.6 (OSGi) >>> >>> * DatasetGraphs & transactions >>> >>> * New module jena-cmds >>> >>> * Logging - log4j marked <optional> >>> >>> * Fuseki: Multiple service per file, shared datasets >>> >>> * JSON result fix type: "literal" not "type": "typed-literal" >>> >>> * Space saving when parsing (FactoryRDF) >>> Parsing RDF now saves space by partial interning RDFTerms >>> created during a each parser run. >> >> >
