On 19 May 2017 at 08:34, Gustavo Fernandes <gustavo(a)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/s...
On Thu, May 18, 2017 at 9:32 PM, Sanne Grinovero <sanne(a)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.morling(a)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 <sanne(a)hibernate.org>:
> >> On 18 May 2017 at 17:31, Gunnar Morling
<gunnar.morling(a)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"
> >>> <sanne(a)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 <anistor(a)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(a)lists.jboss.org
> >>>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>
> >>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/hibernate-dev