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

[Gustavo Fernandes]

-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]

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".

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 
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 
> 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 :
> >> On 18 May 2017 at 17:31, Gunnar Morling 
> 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  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

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

[Yoann Rodiere]

Sanne, the confusions you pointed out were:

   - Thinking it's more efficient than other providers (it's not)
   - Thinking it's integrated to replicated in-memory datastores such as
   Infinispan (it's not)

So you'd want a name that says "it's not persistent" and probably "it's
easy to set up" while not hinting in any way at efficiency or Infinispan
integration.

Some attempts (none of which is perfect, but what is? :) ):

   - naive
   - mock
   - basic
   - jvm-heap
   - java-map (RAMDirectory does use a map to store its "RAMFiles")

The last one may be close to what we're looking for: it clearly says it's
in local RAM, and doesn't hint at Infinispan integration. Some could still
think it's a high-performance implementation, but at some point it's just
interpretation: one could just as well think "if it's so simple that it
just uses a java.util.Map, it must not be very advanced, and thus not very
efficient".


Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 19 May 2017 at 09:34, Gustavo Fernandes  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]
>
> 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".
>
> 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 
> 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 
> > 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 :
> > >> 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  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
> > > repli

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

[Sanne Grinovero]

On 19 May 2017 at 08:34, Gustavo Fernandes  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 
> 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 
>> 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 :
>> >> On 18 May 2017 at 17:31, Gunnar Morling 
>> >> 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"
>> >>> :
>> >>>
>> >>> 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  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
>> >>>

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

[Sanne Grinovero]

On 19 May 2017 at 10:10, Yoann Rodiere  wrote:
> Sanne, the confusions you pointed out were:
>
> Thinking it's more efficient than other providers (it's not)
> Thinking it's integrated to replicated in-memory datastores such as
> Infinispan (it's not)

It's also not scalable in terms of concurrency (at all) and in size
(it will get people into OOM). The "zero durability" aspect is also
not obvious to many.

>
> So you'd want a name that says "it's not persistent" and probably "it's easy
> to set up" while not hinting in any way at efficiency or Infinispan
> integration.
>
> Some attempts (none of which is perfect, but what is? :) ):
>
> naive
> mock
> basic
> jvm-heap
> java-map (RAMDirectory does use a map to store its "RAMFiles")

We need to pick one and only one :)
Gustavo's "local-heap" is a strong contender but personally I think I
still like "testing" more as it sets the goal very clearly. The reason
to pick "local-heap" might be that I can see myself using it in
demos..

> The last one may be close to what we're looking for: it clearly says it's in
> local RAM, and doesn't hint at Infinispan integration. Some could still
> think it's a high-performance implementation, but at some point it's just
> interpretation: one could just as well think "if it's so simple that it just
> uses a java.util.Map, it must not be very advanced, and thus not very
> efficient".

I guess I can take this as a vote for "local-heap".

I hear many technical points, but the reality after years of feedback
is that people don't get it.

If we can take away configuration properties that's a very good thing.
The only reason for which I'm willing to compromise and still have
such an option around is for testing.

Personally I think we need to refactor our documentation and move many
options in to an "advanced only" section, and have a dedicated "how to
test" section. These might be good to document some things which the
main guide will intentionally omit.

>
>
> Yoann Rodière
> Hibernate NoORM Team
> yo...@hibernate.org
>
> On 19 May 2017 at 09:34, Gustavo Fernandes  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]
>>
>> 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".
>>
>> 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 
>> 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 
>> > 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 :
>> > >> On 18 May 2017 at 17:31, Gunnar Morling
>> > >> 
>> > 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  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
>>

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

[Adrian Nistor]

+1 for 'local-heap'.

But I still like 'Buster' :)


On 05/19/2017 10:34 AM, Gustavo Fernandes 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]
>
> 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".
>
> 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 
> 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 
>> 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 :
 On 18 May 2017 at 17:31, Gunnar Morling 
>> 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  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


___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/li

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

[Sanne Grinovero]

On 19 May 2017 at 10:50, Adrian Nistor  wrote:
> +1 for 'local-heap'.

thank you so much to help bringing some consensus!

> But I still like 'Buster' :)

it's cool, but I don't think we can include your geeky explanation in
all logs and error messages :)

>
>
>
> On 05/19/2017 10:34 AM, Gustavo Fernandes 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]
>>
>> 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".
>>
>> 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 
>> 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 
>>> 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 :
>
> On 18 May 2017 at 17:31, Gunnar Morling 
>>>
>>> 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  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] [Search] Deprecating @Boost and related options

[Sanne Grinovero]

Index time boosting is deprecated in Apache Lucene 6, and will be
removed in Lucene 7.

While we currently are using Lucene 5, since we'll likely jump
directly to Lucene 7 with the next major version of Hibernate Search,
I think we should prepare our users already.

Let's deprecate @Boost and any option to control index-time boosting,
so that people can start already to move to query-time boosting.

 - https://hibernate.atlassian.net/browse/HSEARCH-2735
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] JDK 9 EA Build 170 is available on jdk.java.net

[Rory O'Donnell]

Hi Sanne,

*JDK 9 Early Access*  build 170  is available at the new location : - 
jdk.java.net/9/

A summary of all the changes in this build are listed here 
.

Changes which were introduced since the last availability email that may 
be of interest :

  * b168 - JDK-8175814: Update default HttpClient protocol version and
optional request version
  o related to JEP 110  : HTTP/2 Client.
  * b169 - JDK-8178380 : Module system implementation refresh (5/2017)
  o changes in command line options
  * b170 - JDK-8177153  : LambdaMetafactory has default
constructorIncompatible change,
  o release note:  JDK-8180035

*New Proposal - Mark Reinhold has asked for comments on the jigsaw-dev 
mailing list *[1]

  * Proposal: Allow illegal reflective access by default in JDK 9

In short, the existing "big kill switch" of the `--permit-illegal-access`
option [1] will become the default behavior of the JDK 9 run-time system,
though without as many warnings.  The current behavior of JDK 9, in which
illegal reflective-access operations from code on the class path are not
permitted, will become the default in a future release.  Nothing will
change at compile time.


Rgds,Rory

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html

-- 
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA , Dublin, Ireland

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] JDK 9 EA Build 170 is available on jdk.java.net

[Sanne Grinovero]

Hi Rory,

thanks, I'll update our ci.hibernate.org build servers today.

Status reminder: we had good progress some months back, but since
Gradle broke again we're stuck on our flagship project (Hibernate
ORM).

Some progress can be monitored here:
 - http://ci.hibernate.org/view/JDK9/

Please bear in mind that even the "green" projects had to disable
integration tests with various platforms: our goal is to fix our own
code but that doesn't mean that it's going to work in the thousands of
frameworks integrating our projects.

Mark Reinhold's latest proposal looks like a great step into the right
direction.

I can't speak for my colleagues: [I don't represent Red Hat Middleware
!] but indeed - as an opinion from the Hibernate team - having some
ways to mitigate the high time pressure is very well received.
Whatever is decided regarding the default value of that flag, we'll
certainly keep testing on the strictest setting, and keep stressing
integrating frameworks and containers to do the same.

Also as a personal opinion, not having the ability to isolate modules
in terms of avoiding conflicting package names is going to make
progress much harder: several of the projects we integrate with are
extremely conservative in breaking APIs, so renaming packages for the
sake of making the modules system happy is not going to happen in a
long time. Also future evolution of our projects will likely be
affected. In my experience I've witnessed several times that excellent
libraries are "transferred ownership" across organisations and
maintainers, sometimes partially, and when they get split they are
typically not in a suitable time to rename all packages. Sure such
things get cleaned up, but such events have to be decoupled - often
for organisational, practical reasons.

Successful OSS projects grow in size and complexity, but they don't
necessarily scale in funding when they rely on volunteers, so an
organic growth followed by splits is quite natural. The Java ecosystem
supported this nicely; good tooling has been accelerating the process
and allowing for larger projects but we're at a saturation point for
which we're hoping modules would be an enabler for the community to
avoid headaches with dependency alignment puzzles. With no isolation
of at least the not-exported classes this seems like a missed
opportunity.

Thanks,
Sanne



On 19 May 2017 at 11:37, Rory O'Donnell  wrote:
> Hi Sanne,
>
> *JDK 9 Early Access*  build 170  is available at the new location : -
> jdk.java.net/9/
>
> A summary of all the changes in this build are listed here
> .
>
> Changes which were introduced since the last availability email that may
> be of interest :
>
>   * b168 - JDK-8175814: Update default HttpClient protocol version and
> optional request version
>   o related to JEP 110  : HTTP/2 Client.
>   * b169 - JDK-8178380 : Module system implementation refresh (5/2017)
>   o changes in command line options
>   * b170 - JDK-8177153  : LambdaMetafactory has default
> constructorIncompatible change,
>   o release note:  JDK-8180035
>
> *New Proposal - Mark Reinhold has asked for comments on the jigsaw-dev
> mailing list *[1]
>
>   * Proposal: Allow illegal reflective access by default in JDK 9
>
> In short, the existing "big kill switch" of the `--permit-illegal-access`
> option [1] will become the default behavior of the JDK 9 run-time system,
> though without as many warnings.  The current behavior of JDK 9, in which
> illegal reflective-access operations from code on the class path are not
> permitted, will become the default in a future release.  Nothing will
> change at compile time.
>
>
> Rgds,Rory
>
> [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html
>
> --
> Rgds,Rory O'Donnell
> Quality Engineering Manager
> Oracle EMEA , Dublin, Ireland
>
> ___
> 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

Re: [hibernate-dev] JDK 9 EA Build 170 is available on jdk.java.net

[Rory O'Donnell]

Hi Sanne,

I would second Dalibor's request to share your feedback!

Thanks,Rory


On 19/05/2017 13:06, dalibor topic wrote:
> On 19.05.2017 13:49, Sanne Grinovero wrote:
>> Hi Rory,
>>
>> thanks, I'll update our ci.hibernate.org build servers today.
>>
>> Status reminder: we had good progress some months back, but since
>> Gradle broke again we're stuck on our flagship project (Hibernate
>> ORM).
>
> Yeah :/ Aside from the ongoing discussion about getenv improvements 
> for gradle on core-libs-dev, I hope that Mark's latest proposal will 
> help remove some of the roadblocks in this area.
>
> Speaking of which - if you have a spare moment, I think this kind of 
> feedback would be great to have directly on jigsaw-dev. As with many 
> other JDK changes, the potential impact upon framework developers can 
> best be understood by such developers themselves and should be brought 
> back to JDK lists for discussions. In particular when default settings 
> end up changing ;)
>
> cheers,
> dalibor topic
>
>> Some progress can be monitored here:
>>  - http://ci.hibernate.org/view/JDK9/
>>
>> Please bear in mind that even the "green" projects had to disable
>> integration tests with various platforms: our goal is to fix our own
>> code but that doesn't mean that it's going to work in the thousands of
>> frameworks integrating our projects.
>>
>> Mark Reinhold's latest proposal looks like a great step into the right
>> direction.
>>
>> I can't speak for my colleagues: [I don't represent Red Hat Middleware
>> !] but indeed - as an opinion from the Hibernate team - having some
>> ways to mitigate the high time pressure is very well received.
>> Whatever is decided regarding the default value of that flag, we'll
>> certainly keep testing on the strictest setting, and keep stressing
>> integrating frameworks and containers to do the same.
>>
>> Also as a personal opinion, not having the ability to isolate modules
>> in terms of avoiding conflicting package names is going to make
>> progress much harder: several of the projects we integrate with are
>> extremely conservative in breaking APIs, so renaming packages for the
>> sake of making the modules system happy is not going to happen in a
>> long time. Also future evolution of our projects will likely be
>> affected. In my experience I've witnessed several times that excellent
>> libraries are "transferred ownership" across organisations and
>> maintainers, sometimes partially, and when they get split they are
>> typically not in a suitable time to rename all packages. Sure such
>> things get cleaned up, but such events have to be decoupled - often
>> for organisational, practical reasons.
>>
>> Successful OSS projects grow in size and complexity, but they don't
>> necessarily scale in funding when they rely on volunteers, so an
>> organic growth followed by splits is quite natural. The Java ecosystem
>> supported this nicely; good tooling has been accelerating the process
>> and allowing for larger projects but we're at a saturation point for
>> which we're hoping modules would be an enabler for the community to
>> avoid headaches with dependency alignment puzzles. With no isolation
>> of at least the not-exported classes this seems like a missed
>> opportunity.
>>
>> Thanks,
>> Sanne
>>
>>
>>
>> On 19 May 2017 at 11:37, Rory O'Donnell  
>> wrote:
>>> Hi Sanne,
>>>
>>> *JDK 9 Early Access*  build 170  is available at the new location : -
>>> jdk.java.net/9/
>>>
>>> A summary of all the changes in this build are listed here
>>> .
>>>
>>> Changes which were introduced since the last availability email that 
>>> may
>>> be of interest :
>>>
>>>   * b168 - JDK-8175814: Update default HttpClient protocol version and
>>> optional request version
>>>   o related to JEP 110  : HTTP/2 Client.
>>>   * b169 - JDK-8178380 : Module system implementation refresh (5/2017)
>>>   o changes in command line options
>>>   * b170 - JDK-8177153  : LambdaMetafactory has default
>>> constructorIncompatible change,
>>>   o release note:  JDK-8180035
>>>
>>> *New Proposal - Mark Reinhold has asked for comments on the jigsaw-dev
>>> mailing list *[1]
>>>
>>>   * Proposal: Allow illegal reflective access by default in JDK 9
>>>
>>> In short, the existing "big kill switch" of the 
>>> `--permit-illegal-access`
>>> option [1] will become the default behavior of the JDK 9 
>>> run-time system,
>>> though without as many warnings.  The current behavior of JDK 9, 
>>> in which
>>> illegal reflective-access operations from code on the class path 
>>> are not
>>> permitted, will become the default in a future release. Nothing 
>>> will
>>> change at compile time.
>>>
>>>
>>> Rgds,Rory
>>>
>>> [1] 
>>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-May/012673.html
>>>
>>> -- 
>>> Rgds,Rory O'Donnell
>>> Quality Engineering Manager
>>> Oracle EMEA , Dublin, Ireland
>>>
>>> _