On 19 May 2017 at 08:34, Gustavo Fernandes <gust...@infinispan.org> wrote: > -1 to demote it to "testing" > > Let me show the other side of the coin :) > > RAMDirectory has its uses, as long as one understands its limitations. It is > convenient for small non-persistent indexes, and last time I measured, it > was faster to load than the FS directory. > > So it could be used in production (and I believe some people do), and > renaming it to "testing" would feel a bit awkward. One example of production > use of the RAMDirectory is the ES Percolator [1]
There are use cases for RAMDirectory - like your interesting example - but they it's a very specialistic purpose; do you think our main users (of either Cache or Hibernate APIs) would get themselves in a similar scenario? I could possibly imagine someone doing a similar thing with a temporary Infinispan Cache, but I would highly recommend against that: if your data size is large you risk OOM, if it's trivial just use a Map and instantiate a RAMDirectory scoped into a method.. like the example you have shown. Still even ES doesn't give the option *at all* for its primary use case, and the Percolator itself is deprecated legacy: will be removed in the next version. > > We can always throw config errors or log WARN if someone is using "ram" with > clustered caches on Infinispan, but if rebranding is really needed, I'd vote > for something like "local-ram" or "local-heap". "local-heap" : not bad. I'd still want us to be very clear though that it's *never* a good idea to use it, for anything else than tests. Details have been discussed at lenght on the Lucene mailing list, I was equally defending it at least but after years of reading horror stories we have to concede. I could consider "local-heap" as long as it's only documented in a "how to test" context. Sorry but removing features is hard, we have to make hard choices ;) Thanks, Sanne > > Thanks, > Gustavo > > [1] > https://github.com/elastic/elasticsearch/blob/master/modules/percolator/src/main/java/org/elasticsearch/percolator/PercolateQueryBuilder.java > > > > On Thu, May 18, 2017 at 9:32 PM, Sanne Grinovero <sa...@hibernate.org> > wrote: >> >> -1 for "ephemeral" and "volatile", they are pretty much synonyms of >> "ram" with all the same possible confusions, even to the point of >> looking like being the recommended choice for "ephemeral class" >> machines on openstack. >> >> "unreliable": it's not unrelaiable as it's actually very reliable and >> to be recommended for testing, e.g. if you have an issue with our >> other directories I'd love to know if you can reproduce it with this >> one. >> >> I'll go with "testing". I want to be able to recommend it for testing, >> and make it clear it's only meant for that. >> >> >> On 18 May 2017 at 20:22, Gunnar Morling <gunnar.morl...@googlemail.com> >> wrote: >> > I'd argue you can keep the name, if it's in the test JAR. If people >> > still use it in their production code, well... >> > >> > Otherwise, how about "ephemeral"? >> > >> > 2017-05-18 19:05 GMT+02:00 Sanne Grinovero <sa...@hibernate.org>: >> >> On 18 May 2017 at 17:31, Gunnar Morling <gunnar.morl...@googlemail.com> >> >> wrote: >> >>> Can't you just move it to the test JAR if it's for testing only? >> >> >> >> Interesting idea, we can try that as well. >> >> >> >> I'd still want to set the name straight though. Let's agree on a name >> >> first. >> >> >> >>> >> >>> Am 18.05.2017 6:29 nachm. schrieb "Sanne Grinovero" >> >>> <sa...@hibernate.org>: >> >>> >> >>> Right technically it's not a unit test. But I'd like to focus on the >> >>> testing aspect, as "local-ram" might still convey concepts as "fast", >> >>> maybe even expect it to engage Infinispan's off-heap capabilities, or >> >>> just being an option to consider for other reasons. >> >>> >> >>> "testing" ? >> >>> >> >>> On 18 May 2017 at 17:20, Adrian Nistor <anis...@redhat.com> wrote: >> >>>> I agree, but probably "unit-testing" is not such a good name either. >> >>>> Technically, that's a functional test. >> >>>> I think I like "local-ram" better, implying that it is not >> >>>> shared/distributed and it is also volatile. >> >>>> >> >>>> >> >>>> On 05/18/2017 06:07 PM, Sanne Grinovero wrote: >> >>>>> >> >>>>> As anyone who's bothered to read the manual knows, the "ram" >> >>>>> directory >> >>>>> should really only be used for unit tests. The other >> >>>>> implementations, >> >>>>> while typically disk based, are also faster (memory mapped files) >> >>>>> and >> >>>>> more efficient (better locking design) so there's really no reason >> >>>>> to >> >>>>> use it, not even performance except for trivial, small, non >> >>>>> important >> >>>>> data sets. >> >>>>> >> >>>>> For example the Elasticsearch team is making sure of this by having >> >>>>> totally removed the option of using the RAMDirectory - something I >> >>>>> actually don't appreciate as our unit tests could benefit from it, >> >>>>> having slow storage on our test environments. >> >>>>> >> >>>>> Tristan is reporting that the "ram" terminology is confusing people, >> >>>>> not least in the Infinispan community as "RAM" might be ambiguous >> >>>>> since everything is in memory, and people get surprised it's not >> >>>>> replicated in the "in memory cluster". >> >>>>> >> >>>>> I wouldn't want to go to the extremes of the Elasticsearch team as I >> >>>>> believe having this option is very useful, especially for testing. >> >>>>> >> >>>>> Should we rename (rebrand) its short name "ram" into "unit-testing" >> >>>>> ? >> >>>>> >> >>>>> I suspect that would make people think a bit more before pushing it >> >>>>> into production... >> >>>>> >> >>>>> >> >>>>> Thanks, >> >>>>> Sanne >> >>>> >> >>>> >> >>>> >> >>> _______________________________________________ >> >>> hibernate-dev mailing list >> >>> hibernate-dev@lists.jboss.org >> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >>> >> >>> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
