[hibernate-dev] "rebranding" the Hibernate Search "ram" directory

Fri May 19 05:30:20 EDT 2017

On 19 May 2017 at 08:34, Gustavo Fernandes <gustavo at 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 <sanne at 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 at 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 at hibernate.org>:
>> >> On 18 May 2017 at 17:31, Gunnar Morling <gunnar.morling at 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 at 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 at 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 at lists.jboss.org
>> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >>>
>> >>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>