From sanne at infinispan.org  Wed Nov  2 19:12:38 2016
From: sanne at infinispan.org (Sanne Grinovero)
Date: Wed, 2 Nov 2016 23:12:38 +0000
Subject: [infinispan-dev] Spring module - change dependencies to Uber
	Jars
In-Reply-To: <CAFm4XO3ywbjU68Ny0cvM02YEeOY1i1sr2142VR0ttRvCu9fcpQ@mail.gmail.com>
References: <CAA9R9O72cC=kxWikU3sseBDqWkpgKfjuLRHonu-sQRfPagyJqA@mail.gmail.com>
	<CAFm4XO3ywbjU68Ny0cvM02YEeOY1i1sr2142VR0ttRvCu9fcpQ@mail.gmail.com>
Message-ID: <CAFm4XO1TSStKYfDSi+ssd4RpfkonxVBr1MWz0n50E3bCK34w4A@mail.gmail.com>

On 1 February 2016 at 14:12, Sanne Grinovero <sanne at infinispan.org> wrote:
> The Uber Jars will always be more problematic than the "small ones" -
> as the testsuite doesn't cover them at the same level, if at all - so
> I don't think it would be wise to start having components to depend on
> them, especially as this looks like it might become viral: what about
> other component X that people will want to use with Spring?
>
> Also when you're deploying on WildFly you probably want to use the
> Logger from the application server as it's the one being managed. So
> the solution would be wither never use Uber Jars when deploying on the
> container, or remove JBoss Logger from the Uber Jars.
>
> Shall I state once more that the whole Uber Jars affair seems a really
> bad idea to me?

+1 to myself here :) as we're witnessing again reports of issues with them.

Unless someone has a solid explanation about why they are needed,
could we start making plans for their deprecation?

As far as I remember they were introduced to "reduce the number of
dependencies" but this isn't the right way.

Thanks,
Sanne

From gustavo at infinispan.org  Thu Nov  3 05:23:34 2016
From: gustavo at infinispan.org (Gustavo Fernandes)
Date: Thu, 3 Nov 2016 09:23:34 +0000
Subject: [infinispan-dev] Spring module - change dependencies to Uber
	Jars
In-Reply-To: <CAFm4XO1TSStKYfDSi+ssd4RpfkonxVBr1MWz0n50E3bCK34w4A@mail.gmail.com>
References: <CAA9R9O72cC=kxWikU3sseBDqWkpgKfjuLRHonu-sQRfPagyJqA@mail.gmail.com>
	<CAFm4XO3ywbjU68Ny0cvM02YEeOY1i1sr2142VR0ttRvCu9fcpQ@mail.gmail.com>
	<CAFm4XO1TSStKYfDSi+ssd4RpfkonxVBr1MWz0n50E3bCK34w4A@mail.gmail.com>
Message-ID: <CAH8Ud1EYdWO9e19AJg3=T7kcdSX21kv4m3hV+AoqLs8cdOGJ=w@mail.gmail.com>

On Wed, Nov 2, 2016 at 11:12 PM, Sanne Grinovero <sanne at infinispan.org>
wrote:

> On 1 February 2016 at 14:12, Sanne Grinovero <sanne at infinispan.org> wrote:
> > The Uber Jars will always be more problematic than the "small ones" -
> > as the testsuite doesn't cover them at the same level, if at all - so
> > I don't think it would be wise to start having components to depend on
> > them, especially as this looks like it might become viral: what about
> > other component X that people will want to use with Spring?
> >
> > Also when you're deploying on WildFly you probably want to use the
> > Logger from the application server as it's the one being managed. So
> > the solution would be wither never use Uber Jars when deploying on the
> > container, or remove JBoss Logger from the Uber Jars.
> >
> > Shall I state once more that the whole Uber Jars affair seems a really
> > bad idea to me?
>
> +1 to myself here :) as we're witnessing again reports of issues with them.
>
> Unless someone has a solid explanation about why they are needed,
> could we start making plans for their deprecation?
>
> As far as I remember they were introduced to "reduce the number of
> dependencies" but this isn't the right way.
>


+1

Having an uber jar is mostly a convenience for those not using a proper
dependency management
system or doing quick prototypes, but as soon as we start having several
uber jars, putting them
inside osgi bundles and creating jboss modules with them, they become
really alternate jars and
a maintenance burden for very little benefit.

Gustavo



>
> Thanks,
> Sanne
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20161103/52a4df64/attachment.html 

From anistor at redhat.com  Thu Nov  3 06:06:13 2016
From: anistor at redhat.com (Adrian Nistor)
Date: Thu, 3 Nov 2016 12:06:13 +0200
Subject: [infinispan-dev] Names, names, names...
In-Reply-To: <E3B2A617-1558-4337-B249-3D9C81DAC4CA@gmail.com>
References: <dcef4c89-2911-db3f-292c-37eaa5ea36ed@redhat.com>
	<20161028154941.GK2991@hibernate.org>
	<E3B2A617-1558-4337-B249-3D9C81DAC4CA@gmail.com>
Message-ID: <2ed41708-9283-02c1-114f-6be5f897fbb5@redhat.com>

-1. yaql is already taken (multiple times) :)

On 10/28/2016 07:18 PM, Thomas Qvarnstr?m Privat wrote:
> How about YAQL, Yet Another Query Language?
>
>
>> On 28 Oct 2016, at 17:49, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>>
>> I like Ickle and LQID personally. And Adrian is way too reasonable on a
>> name thread ;)
>>
>> On Mon 16-10-17  9:07, Tristan Tarrant wrote:
>>> Hi all,
>>>
>>> something trivial and fun for a Monday morning.
>>>
>>> I've just issued a PR [1] to update the codename for Infinispan 9.0.
>>>
>>> And while we're at it, let's give a name to the new query language that
>>> Adrian (and Emmanuel) have designed. We already have a number of
>>> suggestions (which I summarize below) but please feel free to add your
>>> own. Please vote.
>>>
>>> IQL (Infinispan Query Language, already used by others).
>>> Ickle (Alternate pronunciation of above, also means "small")
>>> LQID (Language for Querying Infinispan Datagrids)
>>> QuIL ("Query Infinispan" Language)
>>>
>>> Tristan
>>>
>>> [1] https://github.com/infinispan/infinispan/pull/4617
>>> -- 
>>> Tristan Tarrant
>>> Infinispan Lead
>>> JBoss, a division of Red Hat
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev



From anistor at redhat.com  Thu Nov  3 06:49:29 2016
From: anistor at redhat.com (Adrian Nistor)
Date: Thu, 3 Nov 2016 12:49:29 +0200
Subject: [infinispan-dev] Names, names, names...
In-Reply-To: <20161028154941.GK2991@hibernate.org>
References: <dcef4c89-2911-db3f-292c-37eaa5ea36ed@redhat.com>
	<20161028154941.GK2991@hibernate.org>
Message-ID: <d415b030-1b00-8f59-52e7-c50258f80179@redhat.com>

Hi all,

So far we have: IQL, Ickle, QuIL, YAQL, LQID, INAQL, INQL, WTF, NSFW, 
KMFDM.

I do not like acronyms that are not straight forward. They should really 
be the initials of the simplest description of what the thing is. In 
this case the acceptable one would be : Infinispan Query Language => 
IQL. Unfortunately this seems to mean different things to different 
people. So let's forget about acronyms and go with ... *Ickle* 
[1][2][3], proposed by Tristan.

A very respectable bearded fellow once said: "There are only two hard 
things in Computer Science: cache invalidation and naming things." So 
let's use this as an excuse and dare to (maybe) settle on a less than 
perfect name :). At least it is a damn cute one.

Thanks Tristan for the name!
Cheers!


[1] http://www.merriam-webster.com/dictionary/ickle
[2] http://www.dictionary.com/browse/ickle
[3] http://www.urbandictionary.com/define.php?term=ickle


On 10/28/2016 06:49 PM, Emmanuel Bernard wrote:
> I like Ickle and LQID personally. And Adrian is way too reasonable on a
> name thread ;)
>
> On Mon 16-10-17  9:07, Tristan Tarrant wrote:
>> Hi all,
>>
>> something trivial and fun for a Monday morning.
>>
>> I've just issued a PR [1] to update the codename for Infinispan 9.0.
>>
>> And while we're at it, let's give a name to the new query language that
>> Adrian (and Emmanuel) have designed. We already have a number of
>> suggestions (which I summarize below) but please feel free to add your
>> own. Please vote.
>>
>> IQL (Infinispan Query Language, already used by others).
>> Ickle (Alternate pronunciation of above, also means "small")
>> LQID (Language for Querying Infinispan Datagrids)
>> QuIL ("Query Infinispan" Language)
>>
>> Tristan
>>
>> [1] https://github.com/infinispan/infinispan/pull/4617
>> -- 
>> Tristan Tarrant
>> Infinispan Lead
>> JBoss, a division of Red Hat
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20161103/682da84e/attachment.html 

From crudbug at gmail.com  Thu Nov  3 12:09:04 2016
From: crudbug at gmail.com (Alan Kash)
Date: Thu, 3 Nov 2016 12:09:04 -0400
Subject: [infinispan-dev] Names, names, names...
In-Reply-To: <d415b030-1b00-8f59-52e7-c50258f80179@redhat.com>
References: <dcef4c89-2911-db3f-292c-37eaa5ea36ed@redhat.com>
	<20161028154941.GK2991@hibernate.org>
	<d415b030-1b00-8f59-52e7-c50258f80179@redhat.com>
Message-ID: <CAJ=bejx22X3xTXNUK1LJNibJ-U8FdW46RLhCP5h2t5mYFJmB2w@mail.gmail.com>

Hi All,

I joined this mailing list few weeks back. I am not sure about the new
query language work, but I would like to suggest one more name option -
*Cantor* - In the spirit of Georg Cantor (
https://en.wikipedia.org/wiki/Georg_Cantor) who put forward the idea of
infinite.

Thanks,
Alan





On Thu, Nov 3, 2016 at 6:49 AM, Adrian Nistor <anistor at redhat.com> wrote:

> Hi all,
>
> So far we have: IQL, Ickle, QuIL, YAQL, LQID, INAQL, INQL, WTF, NSFW,
> KMFDM.
>
> I do not like acronyms that are not straight forward. They should really
> be the initials of the simplest description of what the thing is. In this
> case the acceptable one would be : Infinispan Query Language => IQL.
> Unfortunately this seems to mean different things to different people. So
> let's forget about acronyms and go with ... *Ickle* [1][2][3], proposed
> by Tristan.
>
> A very respectable bearded fellow once said: "There are only two hard
> things in Computer Science: cache invalidation and naming things." So let's
> use this as an excuse and dare to (maybe) settle on a less than perfect
> name :). At least it is a damn cute one.
>
> Thanks Tristan for the name!
> Cheers!
>
>
> [1] http://www.merriam-webster.com/dictionary/ickle
> [2] http://www.dictionary.com/browse/ickle
> [3] http://www.urbandictionary.com/define.php?term=ickle
>
>
>
> On 10/28/2016 06:49 PM, Emmanuel Bernard wrote:
>
> I like Ickle and LQID personally. And Adrian is way too reasonable on a
> name thread ;)
>
> On Mon 16-10-17  9:07, Tristan Tarrant wrote:
>
> Hi all,
>
> something trivial and fun for a Monday morning.
>
> I've just issued a PR [1] to update the codename for Infinispan 9.0.
>
> And while we're at it, let's give a name to the new query language that
> Adrian (and Emmanuel) have designed. We already have a number of
> suggestions (which I summarize below) but please feel free to add your
> own. Please vote.
>
> IQL (Infinispan Query Language, already used by others).
> Ickle (Alternate pronunciation of above, also means "small")
> LQID (Language for Querying Infinispan Datagrids)
> QuIL ("Query Infinispan" Language)
>
> Tristan
>
> [1] https://github.com/infinispan/infinispan/pull/4617
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing listinfinispan-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing listinfinispan-dev at lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20161103/f3f42d9f/attachment-0001.html 

From dan.berindei at gmail.com  Mon Nov  7 10:42:03 2016
From: dan.berindei at gmail.com (Dan Berindei)
Date: Mon, 7 Nov 2016 17:42:03 +0200
Subject: [infinispan-dev] Weekly IRC meeting logs 2016-11-07
Message-ID: <CA+nfvwT0ccE_L+FGfKmhsXBHfTKUw_XKMQLVxM06XKR3KurSiw@mail.gmail.com>

Hi all

The logs of the weekly IRC meeting are at

http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2016/infinispan.2016-11-07-15.04.log.html

Cheers
Dan

From ttarrant at redhat.com  Thu Nov 10 03:38:23 2016
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Thu, 10 Nov 2016 09:38:23 +0100
Subject: [infinispan-dev] Default cache
Message-ID: <6664a2bc-a7aa-4fbb-4386-76916d2f6813@redhat.com>

In the discussion for [1] the subject of the default cache and the way 
it affects configuration inheritance came up.

My proposal is:
- remove the default cache as a special cache altogether
- CacheManager.getCache()  should return the named cache specified as 
default in the configuration.
- the programmatic GlobalConfigurationBuilder/GlobalConfiguration should 
have the notion of the default named cache (currently this is handled in 
the parser)
- Retrieving the cache named "___defaultcache" should actually retrieve 
the above named cache

Opinions ?

Tristan

[1] https://github.com/infinispan/infinispan/pull/4631
-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat

From sanne at infinispan.org  Thu Nov 10 06:55:09 2016
From: sanne at infinispan.org (Sanne Grinovero)
Date: Thu, 10 Nov 2016 11:55:09 +0000
Subject: [infinispan-dev] Default cache
In-Reply-To: <6664a2bc-a7aa-4fbb-4386-76916d2f6813@redhat.com>
References: <6664a2bc-a7aa-4fbb-4386-76916d2f6813@redhat.com>
Message-ID: <CAFm4XO0t8u4dF2uVa2jdPJAwxZ2UccECZPtDHy5=h==Z2oLKtw@mail.gmail.com>

I like it: it makes the existence and the name of the default cache
explicit to the user, with no practical drawbacks.

Thanks,
Sanne


On 10 November 2016 at 08:38, Tristan Tarrant <ttarrant at redhat.com> wrote:

> In the discussion for [1] the subject of the default cache and the way
> it affects configuration inheritance came up.
>
> My proposal is:
> - remove the default cache as a special cache altogether
> - CacheManager.getCache()  should return the named cache specified as
> default in the configuration.
> - the programmatic GlobalConfigurationBuilder/GlobalConfiguration should
> have the notion of the default named cache (currently this is handled in
> the parser)
> - Retrieving the cache named "___defaultcache" should actually retrieve
> the above named cache
>
> Opinions ?
>
> Tristan
>
> [1] https://github.com/infinispan/infinispan/pull/4631
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20161110/83f7b35e/attachment.html 

From paul.ferraro at redhat.com  Thu Nov 10 07:20:41 2016
From: paul.ferraro at redhat.com (Paul Ferraro)
Date: Thu, 10 Nov 2016 07:20:41 -0500
Subject: [infinispan-dev] Default cache
In-Reply-To: <6664a2bc-a7aa-4fbb-4386-76916d2f6813@redhat.com>
References: <6664a2bc-a7aa-4fbb-4386-76916d2f6813@redhat.com>
Message-ID: <CAF5qqoMHF=k3h=qYMwrER1V4q0MkH72B=a3kKUdbzvpsfGUw0A@mail.gmail.com>

+1000

This is precisely how we've setup cache manager semantics in WildFly
(since AS7):
https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/spi/src/main/java/org/wildfly/clustering/infinispan/spi/CacheContainer.java
https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/extension/src/main/java/org/jboss/as/clustering/infinispan/DefaultCacheContainer.java

I'd love to be able to drop this.

Paul

On Thu, Nov 10, 2016 at 3:38 AM, Tristan Tarrant <ttarrant at redhat.com> wrote:
> In the discussion for [1] the subject of the default cache and the way
> it affects configuration inheritance came up.
>
> My proposal is:
> - remove the default cache as a special cache altogether
> - CacheManager.getCache()  should return the named cache specified as
> default in the configuration.
> - the programmatic GlobalConfigurationBuilder/GlobalConfiguration should
> have the notion of the default named cache (currently this is handled in
> the parser)
> - Retrieving the cache named "___defaultcache" should actually retrieve
> the above named cache
>
> Opinions ?
>
> Tristan
>
> [1] https://github.com/infinispan/infinispan/pull/4631
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

From anistor at redhat.com  Thu Nov 10 12:31:46 2016
From: anistor at redhat.com (Adrian Nistor)
Date: Thu, 10 Nov 2016 19:31:46 +0200
Subject: [infinispan-dev] Names, names, names...
In-Reply-To: <CAJ=bejx22X3xTXNUK1LJNibJ-U8FdW46RLhCP5h2t5mYFJmB2w@mail.gmail.com>
References: <dcef4c89-2911-db3f-292c-37eaa5ea36ed@redhat.com>
	<20161028154941.GK2991@hibernate.org>
	<d415b030-1b00-8f59-52e7-c50258f80179@redhat.com>
	<CAJ=bejx22X3xTXNUK1LJNibJ-U8FdW46RLhCP5h2t5mYFJmB2w@mail.gmail.com>
Message-ID: <8077bbeb-a4e1-ac37-fc2e-a9f5aec01a5f@redhat.com>

Alan, thanks for your well thought out suggestion, but for simplicity's 
sake I'll go with Ickle.
That involves far less explaining, just in case anyone asks me what the 
name means :) Occam wins again!

Wait a second.. Occam could have been a pretty good option too ...

Cheers!

On 11/03/2016 06:09 PM, Alan Kash wrote:
> Hi All,
>
> I joined this mailing list few weeks back. I am not sure about the new 
> query language work, but I would like to suggest one more name option 
> - *Cantor* -**In the spirit of Georg 
> Cantor (https://en.wikipedia.org/wiki/Georg_Cantor) who put forward 
> the idea of infinite.
>
> Thanks,
> Alan
>
>
>
>
>
> On Thu, Nov 3, 2016 at 6:49 AM, Adrian Nistor <anistor at redhat.com 
> <mailto:anistor at redhat.com>> wrote:
>
>     Hi all,
>
>     So far we have: IQL, Ickle, QuIL, YAQL, LQID, INAQL, INQL, WTF,
>     NSFW, KMFDM.
>
>     I do not like acronyms that are not straight forward. They should
>     really be the initials of the simplest description of what the
>     thing is. In this case the acceptable one would be : Infinispan
>     Query Language => IQL. Unfortunately this seems to mean different
>     things to different people. So let's forget about acronyms and go
>     with ... *Ickle* [1][2][3], proposed by Tristan.
>
>     A very respectable bearded fellow once said: "There are only two
>     hard things in Computer Science: cache invalidation and naming
>     things." So let's use this as an excuse and dare to (maybe) settle
>     on a less than perfect name :). At least it is a damn cute one.
>
>     Thanks Tristan for the name!
>     Cheers!
>
>
>     [1] http://www.merriam-webster.com/dictionary/ickle
>     <http://www.merriam-webster.com/dictionary/ickle>
>     [2] http://www.dictionary.com/browse/ickle
>     <http://www.dictionary.com/browse/ickle>
>     [3] http://www.urbandictionary.com/define.php?term=ickle
>     <http://www.urbandictionary.com/define.php?term=ickle>
>
>
>
>     On 10/28/2016 06:49 PM, Emmanuel Bernard wrote:
>>     I like Ickle and LQID personally. And Adrian is way too reasonable on a
>>     name thread ;)
>>
>>     On Mon 16-10-17  9:07, Tristan Tarrant wrote:
>>>     Hi all,
>>>
>>>     something trivial and fun for a Monday morning.
>>>
>>>     I've just issued a PR [1] to update the codename for Infinispan 9.0.
>>>
>>>     And while we're at it, let's give a name to the new query language that
>>>     Adrian (and Emmanuel) have designed. We already have a number of
>>>     suggestions (which I summarize below) but please feel free to add your
>>>     own. Please vote.
>>>
>>>     IQL (Infinispan Query Language, already used by others).
>>>     Ickle (Alternate pronunciation of above, also means "small")
>>>     LQID (Language for Querying Infinispan Datagrids)
>>>     QuIL ("Query Infinispan" Language)
>>>
>>>     Tristan
>>>
>>>     [1]https://github.com/infinispan/infinispan/pull/4617
>>>     <https://github.com/infinispan/infinispan/pull/4617>
>>>     -- 
>>>     Tristan Tarrant
>>>     Infinispan Lead
>>>     JBoss, a division of Red Hat
>>>     _______________________________________________
>>>     infinispan-dev mailing list
>>>     infinispan-dev at lists.jboss.org
>>>     <mailto:infinispan-dev at lists.jboss.org>
>>>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>>     _______________________________________________
>>     infinispan-dev mailing list
>>     infinispan-dev at lists.jboss.org
>>     <mailto:infinispan-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev>
>
>     _______________________________________________ infinispan-dev
>     mailing list infinispan-dev at lists.jboss.org
>     <mailto:infinispan-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/infinispan-dev
>     <https://lists.jboss.org/mailman/listinfo/infinispan-dev> 
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20161110/5651d6f2/attachment-0001.html 

From mudokonman at gmail.com  Fri Nov 11 11:16:57 2016
From: mudokonman at gmail.com (William Burns)
Date: Fri, 11 Nov 2016 16:16:57 +0000
Subject: [infinispan-dev] Data Container configuration changes
In-Reply-To: <b848cfb0-8750-0c87-bc49-c68ad5204c6a@redhat.com>
References: <CA+YCuUNAxm2M3bwSYSzRtgW-ORjXwMiAKdcXepxsnQHvXFy9qw@mail.gmail.com>
	<122bcbd2-bb36-815e-c69d-b19f3716362d@infinispan.org>
	<CA+YCuUO8_f+T99rbqEuODaK7wV5bJAGL0gNPToMdoj1kx1KqHg@mail.gmail.com>
	<e7e5c817-fd6f-ec72-b150-b552114fa388@infinispan.org>
	<CA+YCuUMQaRNSs1qgxKYfHLvre9TRQCiMirxmfvCgANf-zRNnUQ@mail.gmail.com>
	<b848cfb0-8750-0c87-bc49-c68ad5204c6a@redhat.com>
Message-ID: <CA+YCuUM-KhKhMmDsFMoxDjiXS9C+E_zWiRrFAGUTdRQp=yBGHg@mail.gmail.com>

Since I have had some time to think it over I like Pedro's layout, unless
someone has a strong objection.

Responses inline.

On Mon, Oct 31, 2016 at 4:51 AM Radim Vansa <rvansa at redhat.com> wrote:

> On 10/27/2016 05:26 PM, William Burns wrote:
> >
> >
> > On Thu, Oct 27, 2016 at 9:56 AM Pedro Ruivo <pedro at infinispan.org
> > <mailto:pedro at infinispan.org>> wrote:
> >
> >
> >
> >     On 27-10-2016 14:20, William Burns wrote:
> >     >
> >     >
> >     > On Thu, Oct 27, 2016 at 4:56 AM Pedro Ruivo
> >     <pedro at infinispan.org <mailto:pedro at infinispan.org>
> >     > <mailto:pedro at infinispan.org <mailto:pedro at infinispan.org>>>
> wrote:
> >     >
> >     >
> >     >
> >     >     On 26-10-2016 23:06, William Burns wrote:
> >     >     > I have been working on adding in off heap support for a given
> >     >     cache.  I
> >     >     > wanted to check in and let you all know what I was
> >     thinking for the
> >     >     > configuration and changes that would come about with it.
> >     >     >
> >     >     > TLDR;
> >     >     > New config under data container to enable off heap,
> >     StoreAsBinary
> >     >     > removed, Equivalence removed
> >     >     >
> >     >     > First I was planning on adding new sub elements of data
> >     container.
> >     >     > These would be instance, binary and off-heap. Only of the
> >     three could
> >     >     > be picked as they are mutually exclusive. Instance is as we
> >     >     operate now
> >     >     > where we store the instance of the object passed to us.
> >     Binary is
> >     >     > essentially what we have now that is called storeAsBinary
> with
> >     >     both keys
> >     >     > and values converted.  Lastly off-heap would store the
> >     entry as a
> >     >     byte[]
> >     >     > store completely in native memory.
> >     >
> >     >     I prefer 'object' instead of 'instance'.
> >     >
> >     >
> >     > Sounds fine with me.
> >     >
> >     >
> >     >
> >     >     Are you also planning to remove the expiration and/or eviction
> >     >     configuration elements and set them in the data-container
> >     sub elements?
> >     >
> >     >
> >     > I wasn't planning on touching those.  But now that you mention it,
> >     > eviction only makes sense in the data container, where as
> >     expiration is
> >     > container and cache store.  And taking this further storeAsBinary
> is
> >     > both as well, only off-heap is container only.  I wonder if
> >     instead we
> >     > should have a separate storage element at the same level as
> >     > data-container.  I can see it either way.
> >
> >     Let me know if this makes sense:
> >
> >     <expiration> //no changes here
> >     <memory evictionStrategy=... evictionPolicy=...>
>

There wouldn't be any elements here.  The strategy would always be TinyLFU
as this is all Caffeine supports.  The thread policy though is interesting,
I would say for now don't let it be configured and it will run in the same
thead.  However Caffeine does have async eviction which we could utilize in
the future.  But I think we can look into that later and not part of this.


> >
> >     //one of the following
> >          <on-heap max-entries=.../>
> >          <on-heap-binary max-size=.../>
> >          <off-heap ...max-size? and off-heap config.../>
>

I think I like the naming of the elements as OBJECT, BINARY and
OFF-HEAP/NATIVE that Radim mentioned.

I am thinking for now OBJECT would only support max-entries and the other 2
could support both max-entries or max-size.


> >
> >     </memory>
> >     <persistence> //no changes here
> >
> >     wdyt?
> >
>
> While I prefer "on-heap" instead of "object" or "instance", I don't
> think that "binary" should be its own element. Are there any attributes
> specific to that (do you plan to have keys="false" values="true"? I
> guess not). "on-heap" and "off-heap" is a binary ( :-) ) option,
> "on-heap-binary" is just a flavour of "on-heap".
>

Right now the plan is to remove keys and values and always do both.  But we
may have to change that later, I don't know.  Having separate elements
gives us more flexibility which I like.


>
> For comparison, HC uses
> <in-memory-format>OBJECT|BINARY|NATIVE</in-memory-format> where "NATIVE"
> means off-heap. I like "format= OBJECT|BINARY" as a child of on-heap,
> either as attribute or element. I haven't found similar settings in
> Coherence - seems that they store data in a serialized form only when
> they persist to disk/flash or offload to non-managed memory.
>

> Regarding Equivalence: can't we wrap objects in a similar way we do with
> byte[] if Equivalance (different from AnyInstance) is defined? I can
> definitely see use case when the hashCode() is not very well defined and
> user can't change the class - he has to wrap the objects themselves.
>

Hrmm we could add that back in if it is really needed.  As far as I know
though no one has really used this.  I would rather make it more
minimalistic to begin with and add back on as we find we need features.


>
> R.
>
> >
> > Seems fine to me.  And to be honest I forgot to mention this but
> > EvictionStrategy and EvictionPolicy are completely redundant now.
> > Policy has been for a while as we always used the same thread and
> > Strategy is only Caffeine and for off heap I was thinking of a simple
> LRU.
> >
> > This means that the data container element would be removed in favor
> > of "memory"?  The reason being is that equivalence will be gone and
> > afaik we never really supported a custom data container (eviction
> > wouldn't work with it and neither would off heap).  In that case why
> > not just keep using data container element?
> >
> >     >
> >     >
> >     >
> >     >
> >     >     >
> >     >     > Example:
> >     >     >
> >     >     >  <data-container>
> >     >     >    <off-heap/>
> >     >     >   </data-container>
> >     >     >
> >     >     > The reason it is a subelement instead of a property is
> because
> >     >     off-heap
> >     >     > will most likely require some additional configuration to
> >     tell how
> >     >     many
> >     >     > entries to store in the a bucket (think non resizing
> HashMap).
> >     >     >
> >     >     > With these changes storeAsBinary becomes redundant, so I was
> >     >     planning on
> >     >     > removing this configuration completely.  I would rather
> >     remove since
> >     >     > this is 9.0 and not deprecate.  As far as I know nobody
> >     really used it
> >     >     > before.
> >     >     >
> >     >     > Also another side effect is I was removing all of the
> >     Equivalence
> >     >     > classes.  I am not sure if I can plainly remove them since
> >     they have
> >     >     > lived in commons for quite a while, but it would be best
> >     if I could,
> >     >     > although I am fine deprecating.  In its place the instance
> >     setting for
> >     >     > data-container will always wrap byte[] to satisfy equals
> >     and hashCode
> >     >     > methods.
> >     >     >
> >     >     > Any feedback would be appreciated.
> >     >     >
> >     >     > Thanks,
> >     >     >  - Will
> >     >     >
> >     >     >
> >     >     > _______________________________________________
> >     >     > infinispan-dev mailing list
> >     >     > infinispan-dev at lists.jboss.org
> >     <mailto:infinispan-dev at lists.jboss.org>
> >     <mailto:infinispan-dev at lists.jboss.org
> >     <mailto:infinispan-dev at lists.jboss.org>>
> >     >     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >     >     >
> >     >     _______________________________________________
> >     >     infinispan-dev mailing list
> >     > infinispan-dev at lists.jboss.org
> >     <mailto:infinispan-dev at lists.jboss.org>
> >     <mailto:infinispan-dev at lists.jboss.org
> >     <mailto:infinispan-dev at lists.jboss.org>>
> >     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >     >
> >     >
> >     >
> >     > _______________________________________________
> >     > infinispan-dev mailing list
> >     > infinispan-dev at lists.jboss.org
> >     <mailto:infinispan-dev at lists.jboss.org>
> >     > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >     >
> >     _______________________________________________
> >     infinispan-dev mailing list
> >     infinispan-dev at lists.jboss.org <mailto:
> infinispan-dev at lists.jboss.org>
> >     https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> >
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Radim Vansa <rvansa at redhat.com>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20161111/0de94bbe/attachment-0001.html 

From rory.odonnell at oracle.com  Mon Nov 14 07:31:05 2016
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Mon, 14 Nov 2016 12:31:05 +0000
Subject: [infinispan-dev] JDK 9 & JDK 9 with Project Jigsaw b144 are
	available on java.net
Message-ID: <8011385e-dbf6-cdbc-bb99-cdb8b1239305@oracle.com>


Hi Galder,

Early Access b144 <https://jdk9.java.net/jigsaw/> (#5709) for JDK 9 with 
Project Jigsaw is available on java.net, summary of changes are listed 
here. 
<http://www.java.net/download/java/jigsaw/archive/144/binaries/jdk-9+144.html>

Early Access b144 <https://jdk9.java.net/download/> for JDK 9 is 
available on java.net, summary of  changes are listed here 
<http://www.java.net/download/java/jdk9/changes/jdk-9+144.html>.

There have been a number of fixes to bugs reported by Open Source 
projects since the last availability email  :

  * JDK-8156149 : Blurry rendering on Windows 7 at 125% screen setting
  * JDK-8167431 : tools javac takes too long time to resolve interface
    dependency
  * JDK-8062810 : infrastructure Examine src.zip in JDK image and decide
    if source classes should be organized by module

*Proposal* - latest update

  *    b142 of JDK 9 with project Jigsaw has the initial implementation
    of open modules and open packages as detailed in the recent proposal
    for #ReflectiveAccessToNonExportedTypes [1]

*Tool*

     Adapted from JEP 277 [2]

  * A static analysis tool jdeprscan has been provided that scans a jar
    file (or some other aggregation of class files) for uses of
    deprecated API elements.

*Schedule*

  * The proposed JDK 9 schedule has been adopted and posted on the Open
    JDK 9 Project Page [3]


Rgds,Rory

[1] 
http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-October/000430.html
[2] http://openjdk.java.net/jeps/277
[3] http://openjdk.java.net/projects/jdk9/

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20161114/1ede95f5/attachment.html 

From rvansa at redhat.com  Mon Nov 14 09:26:45 2016
From: rvansa at redhat.com (Radim Vansa)
Date: Mon, 14 Nov 2016 15:26:45 +0100
Subject: [infinispan-dev] Triangle and ISPN-3918
Message-ID: <66269dfd-d2dd-a8f0-9c79-455b2b61a7e2@redhat.com>

Hi,

I was thinking about ISPN-3918 [1] and I've realized that while this 
happens in current implementation only rarely during state transfer, 
with Triangle v4 this could happen more often.

Conditional command is always executed on primary owner, and so far 
during the execution of conditional command (incl. replication to 
backup-owners) the other commands to the same key were blocking in the 
locking layer. Triangle v4 removes this blocking, and if in thread T1 
you do:

T1: replace(key, A, B)

and in second thread T2

T2: replace(key, A, C)
T2: get(key)

the T2.replace can now fail before the T1.replace (successful) is 
replicated to backup owner. When T2 is, by chance, the backup owner, the 
T2.replace completes with false, the T2.get will be served locally and 
it will still returns A.

We should decide if this is an issue, and either close ISPN-3918 (not a 
bug) or think about triangle routing of unsuccessful commands.

Radim

[1] https://issues.jboss.org/browse/ISPN-3918

-- 
Radim Vansa <rvansa at redhat.com>
JBoss Performance Team


From pedro at infinispan.org  Mon Nov 14 09:49:20 2016
From: pedro at infinispan.org (Pedro Ruivo)
Date: Mon, 14 Nov 2016 14:49:20 +0000
Subject: [infinispan-dev] Triangle and ISPN-3918
In-Reply-To: <66269dfd-d2dd-a8f0-9c79-455b2b61a7e2@redhat.com>
References: <66269dfd-d2dd-a8f0-9c79-455b2b61a7e2@redhat.com>
Message-ID: <df263dfe-0eb0-3487-ded2-3971da73ca83@infinispan.org>



On 14-11-2016 14:26, Radim Vansa wrote:
> Hi,
>
> I was thinking about ISPN-3918 [1] and I've realized that while this
> happens in current implementation only rarely during state transfer,
> with Triangle v4 this could happen more often.
>
> Conditional command is always executed on primary owner, and so far
> during the execution of conditional command (incl. replication to
> backup-owners) the other commands to the same key were blocking in the
> locking layer. Triangle v4 removes this blocking, and if in thread T1
> you do:
>
> T1: replace(key, A, B)
>
> and in second thread T2
>
> T2: replace(key, A, C)
> T2: get(key)
>
> the T2.replace can now fail before the T1.replace (successful) is
> replicated to backup owner. When T2 is, by chance, the backup owner, the
> T2.replace completes with false, the T2.get will be served locally and
> it will still returns A.
>
> We should decide if this is an issue, and either close ISPN-3918 (not a
> bug) or think about triangle routing of unsuccessful commands.

well... I think we could send the unsuccessful ack in FIFO order(*1). In 
this way, it would force the backup owner to process the T1 operation 
before processing the ack. get() will then return the correct value.

*1 or send only in FIFO when the backup owner is the originator and the 
command is unsuccessful.
*1 or merge the ack command + backup-write command and send them in FIFO

>
> Radim
>
> [1] https://issues.jboss.org/browse/ISPN-3918
>

From dan.berindei at gmail.com  Mon Nov 14 11:06:20 2016
From: dan.berindei at gmail.com (Dan Berindei)
Date: Mon, 14 Nov 2016 18:06:20 +0200
Subject: [infinispan-dev] Triangle and ISPN-3918
In-Reply-To: <df263dfe-0eb0-3487-ded2-3971da73ca83@infinispan.org>
References: <66269dfd-d2dd-a8f0-9c79-455b2b61a7e2@redhat.com>
	<df263dfe-0eb0-3487-ded2-3971da73ca83@infinispan.org>
Message-ID: <CA+nfvwSC72OEA0Eh6ZE2rkMEvz7wBmsCVF3jEJPz+BuWA=sauQ@mail.gmail.com>

On Mon, Nov 14, 2016 at 4:49 PM, Pedro Ruivo <pedro at infinispan.org> wrote:
>
>
> On 14-11-2016 14:26, Radim Vansa wrote:
>> Hi,
>>
>> I was thinking about ISPN-3918 [1] and I've realized that while this
>> happens in current implementation only rarely during state transfer,
>> with Triangle v4 this could happen more often.
>>
>> Conditional command is always executed on primary owner, and so far
>> during the execution of conditional command (incl. replication to
>> backup-owners) the other commands to the same key were blocking in the
>> locking layer. Triangle v4 removes this blocking, and if in thread T1
>> you do:
>>
>> T1: replace(key, A, B)
>>
>> and in second thread T2
>>
>> T2: replace(key, A, C)
>> T2: get(key)
>>
>> the T2.replace can now fail before the T1.replace (successful) is
>> replicated to backup owner. When T2 is, by chance, the backup owner, the
>> T2.replace completes with false, the T2.get will be served locally and
>> it will still returns A.
>>
>> We should decide if this is an issue, and either close ISPN-3918 (not a
>> bug) or think about triangle routing of unsuccessful commands.
>
> well... I think we could send the unsuccessful ack in FIFO order(*1). In
> this way, it would force the backup owner to process the T1 operation
> before processing the ack. get() will then return the correct value.
>
> *1 or send only in FIFO when the backup owner is the originator and the
> command is unsuccessful.
> *1 or merge the ack command + backup-write command and send them in FIFO
>

Merging sounds like it would send too much extra stuff to the
originator. Sending only the ack command to the originator when it's
also a backup owner (and making it FIFO) sounds much better :)

OTOH, having T2 run on the backup owner guarantees that get() will
look up the key locally, but there is a chance of that happening when
T2 runs on any non-owner. So I don't think making the ack command FIFO
would really solve the problem.

The more I think about it, the more it seems this bug is just another
example of distributed caches not having session consistency [1]. The
fact is that distributed caches allow read operations to return the
values of concurrent writes in a any order, and having one of those
reads be also a write muddies the water a bit, but doesn't really
change anything. (Except, of course, an implementation that makes it
preserve the order most of the time in master.)

I vote to close ISPN-3918, but I would like to open another issue (or
reuse this one) to add a "force consistent read"
operation/flag/configuration that would force the cache to read the
value from the primary owner. We've been talking about this a lot, and
at the very least we need to have the option so we know whether users
actually choose it.

[1]: https://github.com/infinispan/infinispan/wiki/Consistency-guarantees-in-Infinispan#41-non-transactional

From galder at redhat.com  Mon Nov 14 11:05:08 2016
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Mon, 14 Nov 2016 17:05:08 +0100
Subject: [infinispan-dev] Missing Externalizers for the Lucene Query
	classes
In-Reply-To: <CAFm4XO0Z7BPK9c8wuUOdHK3Q=_DAAvoyRgik9eXZ3xbCZYQ7iw@mail.gmail.com>
References: <CAFm4XO0Z7BPK9c8wuUOdHK3Q=_DAAvoyRgik9eXZ3xbCZYQ7iw@mail.gmail.com>
Message-ID: <DFC4D697-1F6E-455D-85B4-4197C1E470F2@redhat.com>


--
Galder Zamarre?o
Infinispan, Red Hat

> On 31 Oct 2016, at 19:52, Sanne Grinovero <sanne at infinispan.org> wrote:
> 
> Following up on today's meeting minutes.
> 
> Galder asked if Hibernate Search was going to provide externalizers
> for the Lucene Query classes; let me clarify that I don't think that
> those belong in the Hibernate Search code base, not least we hope to
> avoid ever needing to implement them.
> 
> A soft reason to not have them in Hibernate Search is that this
> project never needs to serialise any Query; this is a requirement of
> Infinispan Query only, needed to implement Infinispan specific
> extensions to the query engine.
> Although, these are very nice extensions so I'd not like to see them
> dropped: I'd hope that Infinispan could work around the lack of proper
> externalizers for the moment, as it has always been able to do so far.

^ We can only workaround it because the external marshaller right now relies on JBoss Marshalling, which enables us to plug in at the object table level even for Serializable objects and we can lookup externalizers.

I know for a fact we can't plug like that if using standard serialization, and there's no guarantee that we'll be able to support this use case with another marshaller.

So, we should really be avoiding such edge cases. I don't mind where the externalizers are placed.

> 
> A stronger reason is that this would introduce circular dependencies
> between the two projects, and a big overhead of release coordination:
> we had this in the past, very all very glad this is in the past!
> 
> When we'll have IQL, this will both define a good "on the wire"
> representation which would solve the serialization problem, and IQL
> will also limit the amount of Query types which we will need to
> support, as at that point we will be able to limit the support for
> Clustered Queries (which is the feature needing to serialize the
> queries) to those which IQL can express, and thus serialize.
> 
> At that point we'll be able to deprecate the the Clustered Query API
> which accepts a user instance of the Lucene Query, and only run
> clustered queries for queries expressed over IQL. Not least we'll be
> able to automatically determine if the query is best run as a
> clustered query or as a local query, removing this complexity from the
> user's responsibilities.
> 
> In conclusion, we'll still be using the "Clustered Query"
> functionality, but not exposing it, and by doing so we won't need any
> externalizer. But for now please keep the tests running with the
> existing externalizer strategies: we just need to keep it functional,
> but there's no need to optimise performance of these externalizers as
> we'll get rid of them.
> 
> Thanks,
> Sanne
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev



From crudbug at gmail.com  Mon Nov 14 12:26:56 2016
From: crudbug at gmail.com (Alan Kash)
Date: Mon, 14 Nov 2016 12:26:56 -0500
Subject: [infinispan-dev] Off-Heap Storage Query
Message-ID: <CAJ=bejwo9fU9gRZNh8zbpB78O+Wbxtguq8L7JnKAOALRnsRQgw@mail.gmail.com>

Hi,

Is there any architecture document of Off-Heap storage architecture. Do we
have an ETA for this feature.
Are we using any standard library for  storage ? I looked online, the
Apache Cassandra project has abstracted the Off-Heap functionality into

https://github.com/snazy/ohc

Thanks,
Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20161114/6deceabc/attachment.html 

From mudokonman at gmail.com  Mon Nov 14 13:29:54 2016
From: mudokonman at gmail.com (William Burns)
Date: Mon, 14 Nov 2016 18:29:54 +0000
Subject: [infinispan-dev] Off-Heap Storage Query
In-Reply-To: <CAJ=bejwo9fU9gRZNh8zbpB78O+Wbxtguq8L7JnKAOALRnsRQgw@mail.gmail.com>
References: <CAJ=bejwo9fU9gRZNh8zbpB78O+Wbxtguq8L7JnKAOALRnsRQgw@mail.gmail.com>
Message-ID: <CA+YCuUOcqBpvmUEeix9KUO626e9uOWWpSqeyhwjr9BaHRyDPLQ@mail.gmail.com>

On Mon, Nov 14, 2016 at 12:27 PM Alan Kash <crudbug at gmail.com> wrote:

> Hi,
>
> Is there any architecture document of Off-Heap storage architecture. Do we
> have an ETA for this feature.
>

I am planning on creating a PR for this week assuming everything goes
well.  The required PRs to be integrated before this can go in though are
still waiting though.

I will be adding official documentation for it soon after.  Just trying to
get it in at this point.


> Are we using any standard library for  storage ? I looked online, the
> Apache Cassandra project has abstracted the Off-Heap functionality into
>

No the upcoming implementation is all home grown.  This is the second
iteration of the implementation, the first used the Netty allocator to
perform all the various allocations.  However the new implementation is
100% off heap using Unsafe for allocations.


>
> https://github.com/snazy/ohc
>
> Thanks,
> Alan
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20161114/0fd719dd/attachment-0001.html 

From crudbug at gmail.com  Mon Nov 14 17:00:31 2016
From: crudbug at gmail.com (Alan Kash)
Date: Mon, 14 Nov 2016 17:00:31 -0500
Subject: [infinispan-dev] Off-Heap Storage Query
In-Reply-To: <CA+YCuUOcqBpvmUEeix9KUO626e9uOWWpSqeyhwjr9BaHRyDPLQ@mail.gmail.com>
References: <CAJ=bejwo9fU9gRZNh8zbpB78O+Wbxtguq8L7JnKAOALRnsRQgw@mail.gmail.com>
	<CA+YCuUOcqBpvmUEeix9KUO626e9uOWWpSqeyhwjr9BaHRyDPLQ@mail.gmail.com>
Message-ID: <CAJ=bejx5rOgjhyqbCMxDtGxUQDm2ObY+-5LF_+Jg+ohsED4ubw@mail.gmail.com>

Thanks Will,

Just another question, does your implementation has JMX integration for
storage monitoring metrics - Total Bytes / Classes Types / Indexes/ Access
time etc. ? I am thinking of Classes as buckets.

Is the API designed for generic storage applications. I am thinking what
Netty did for networking, we can have a similar API abstraction for
Storage. This will be great for JVM.





On Mon, Nov 14, 2016 at 1:29 PM, William Burns <mudokonman at gmail.com> wrote:

>
>
> On Mon, Nov 14, 2016 at 12:27 PM Alan Kash <crudbug at gmail.com> wrote:
>
>> Hi,
>>
>> Is there any architecture document of Off-Heap storage architecture. Do
>> we have an ETA for this feature.
>>
>
> I am planning on creating a PR for this week assuming everything goes
> well.  The required PRs to be integrated before this can go in though are
> still waiting though.
>
> I will be adding official documentation for it soon after.  Just trying to
> get it in at this point.
>
>
>> Are we using any standard library for  storage ? I looked online, the
>> Apache Cassandra project has abstracted the Off-Heap functionality into
>>
>
> No the upcoming implementation is all home grown.  This is the second
> iteration of the implementation, the first used the Netty allocator to
> perform all the various allocations.  However the new implementation is
> 100% off heap using Unsafe for allocations.
>
>
>>
>> https://github.com/snazy/ohc
>>
>> Thanks,
>> Alan
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20161114/4e223d8a/attachment.html 

From sanne at infinispan.org  Tue Nov 15 06:48:34 2016
From: sanne at infinispan.org (Sanne Grinovero)
Date: Tue, 15 Nov 2016 11:48:34 +0000
Subject: [infinispan-dev] Missing Externalizers for the Lucene Query
	classes
In-Reply-To: <DFC4D697-1F6E-455D-85B4-4197C1E470F2@redhat.com>
References: <CAFm4XO0Z7BPK9c8wuUOdHK3Q=_DAAvoyRgik9eXZ3xbCZYQ7iw@mail.gmail.com>
	<DFC4D697-1F6E-455D-85B4-4197C1E470F2@redhat.com>
Message-ID: <CAFm4XO38QkQOf5RiEgyXeCFgHTtWrZb6FVr519XByOtw=JLfNg@mail.gmail.com>

On 14 November 2016 at 16:05, Galder Zamarre?o <galder at redhat.com> wrote:
>
>
> --
> Galder Zamarre?o
> Infinispan, Red Hat
>
> > On 31 Oct 2016, at 19:52, Sanne Grinovero <sanne at infinispan.org> wrote:
> >
> > Following up on today's meeting minutes.
> >
> > Galder asked if Hibernate Search was going to provide externalizers
> > for the Lucene Query classes; let me clarify that I don't think that
> > those belong in the Hibernate Search code base, not least we hope to
> > avoid ever needing to implement them.
> >
> > A soft reason to not have them in Hibernate Search is that this
> > project never needs to serialise any Query; this is a requirement of
> > Infinispan Query only, needed to implement Infinispan specific
> > extensions to the query engine.
> > Although, these are very nice extensions so I'd not like to see them
> > dropped: I'd hope that Infinispan could work around the lack of proper
> > externalizers for the moment, as it has always been able to do so far.
>
> ^ We can only workaround it because the external marshaller right now relies on JBoss Marshalling, which enables us to plug in at the object table level even for Serializable objects and we can lookup externalizers.
>
> I know for a fact we can't plug like that if using standard serialization, and there's no guarantee that we'll be able to support this use case with another marshaller.
>
> So, we should really be avoiding such edge cases. I don't mind where the externalizers are placed.


Hi Galder,

sorry but I don't understand if you're asking us to do something, and
what is the proposal?

I'd strongly prefer to keep them as-is for now, and refactor this as
needed in the near future when we'll change the Clustered Query API
and take advantage of ICKLE.

Thanks,
Sanne

>
>
> >
> > A stronger reason is that this would introduce circular dependencies
> > between the two projects, and a big overhead of release coordination:
> > we had this in the past, very all very glad this is in the past!
> >
> > When we'll have IQL, this will both define a good "on the wire"
> > representation which would solve the serialization problem, and IQL
> > will also limit the amount of Query types which we will need to
> > support, as at that point we will be able to limit the support for
> > Clustered Queries (which is the feature needing to serialize the
> > queries) to those which IQL can express, and thus serialize.
> >
> > At that point we'll be able to deprecate the the Clustered Query API
> > which accepts a user instance of the Lucene Query, and only run
> > clustered queries for queries expressed over IQL. Not least we'll be
> > able to automatically determine if the query is best run as a
> > clustered query or as a local query, removing this complexity from the
> > user's responsibilities.
> >
> > In conclusion, we'll still be using the "Clustered Query"
> > functionality, but not exposing it, and by doing so we won't need any
> > externalizer. But for now please keep the tests running with the
> > existing externalizer strategies: we just need to keep it functional,
> > but there's no need to optimise performance of these externalizers as
> > we'll get rid of them.
> >
> > Thanks,
> > Sanne
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


From gustavo at infinispan.org  Tue Nov 15 07:07:12 2016
From: gustavo at infinispan.org (Gustavo Fernandes)
Date: Tue, 15 Nov 2016 12:07:12 +0000
Subject: [infinispan-dev] Missing Externalizers for the Lucene Query
	classes
In-Reply-To: <CAFm4XO38QkQOf5RiEgyXeCFgHTtWrZb6FVr519XByOtw=JLfNg@mail.gmail.com>
References: <CAFm4XO0Z7BPK9c8wuUOdHK3Q=_DAAvoyRgik9eXZ3xbCZYQ7iw@mail.gmail.com>
	<DFC4D697-1F6E-455D-85B4-4197C1E470F2@redhat.com>
	<CAFm4XO38QkQOf5RiEgyXeCFgHTtWrZb6FVr519XByOtw=JLfNg@mail.gmail.com>
Message-ID: <CAH8Ud1HjCdyJWg4Tcw2E_=xMNrEKGUGQbKe6SZFqb7Fn2uT9xA@mail.gmail.com>

On Tue, Nov 15, 2016 at 11:48 AM, Sanne Grinovero <sanne at infinispan.org>
wrote:

> On 14 November 2016 at 16:05, Galder Zamarre?o <galder at redhat.com> wrote:
> >
> >
> > --
> > Galder Zamarre?o
> > Infinispan, Red Hat
> >
> > > On 31 Oct 2016, at 19:52, Sanne Grinovero <sanne at infinispan.org>
> wrote:
> > >
> > > Following up on today's meeting minutes.
> > >
> > > Galder asked if Hibernate Search was going to provide externalizers
> > > for the Lucene Query classes; let me clarify that I don't think that
> > > those belong in the Hibernate Search code base, not least we hope to
> > > avoid ever needing to implement them.
> > >
> > > A soft reason to not have them in Hibernate Search is that this
> > > project never needs to serialise any Query; this is a requirement of
> > > Infinispan Query only, needed to implement Infinispan specific
> > > extensions to the query engine.
> > > Although, these are very nice extensions so I'd not like to see them
> > > dropped: I'd hope that Infinispan could work around the lack of proper
> > > externalizers for the moment, as it has always been able to do so far.
> >
> > ^ We can only workaround it because the external marshaller right now
> relies on JBoss Marshalling, which enables us to plug in at the object
> table level even for Serializable objects and we can lookup externalizers.
> >
> > I know for a fact we can't plug like that if using standard
> serialization, and there's no guarantee that we'll be able to support this
> use case with another marshaller.
> >
> > So, we should really be avoiding such edge cases. I don't mind where the
> externalizers are placed.
>
>
> Hi Galder,
>
> sorry but I don't understand if you're asking us to do something, and
> what is the proposal?
>


As I pointed out before, the short term solution is [1]: we will add an
Externalizer *on Infinispan* for the HSearch
classes that don't have one and are affected by Clustered Queries. This
should remove the edge case altogether and no change is
required on Hibernate Search side


[1] https://issues.jboss.org/browse/ISPN-7156

Thanks,
Gustavo


>
> I'd strongly prefer to keep them as-is for now, and refactor this as
> needed in the near future when we'll change the Clustered Query API
> and take advantage of ICKLE.
>
> Thanks,
> Sanne
>
> >
> >
> > >
> > > A stronger reason is that this would introduce circular dependencies
> > > between the two projects, and a big overhead of release coordination:
> > > we had this in the past, very all very glad this is in the past!
> > >
> > > When we'll have IQL, this will both define a good "on the wire"
> > > representation which would solve the serialization problem, and IQL
> > > will also limit the amount of Query types which we will need to
> > > support, as at that point we will be able to limit the support for
> > > Clustered Queries (which is the feature needing to serialize the
> > > queries) to those which IQL can express, and thus serialize.
> > >
> > > At that point we'll be able to deprecate the the Clustered Query API
> > > which accepts a user instance of the Lucene Query, and only run
> > > clustered queries for queries expressed over IQL. Not least we'll be
> > > able to automatically determine if the query is best run as a
> > > clustered query or as a local query, removing this complexity from the
> > > user's responsibilities.
> > >
> > > In conclusion, we'll still be using the "Clustered Query"
> > > functionality, but not exposing it, and by doing so we won't need any
> > > externalizer. But for now please keep the tests running with the
> > > existing externalizer strategies: we just need to keep it functional,
> > > but there's no need to optimise performance of these externalizers as
> > > we'll get rid of them.
> > >
> > > Thanks,
> > > Sanne
> > > _______________________________________________
> > > infinispan-dev mailing list
> > > infinispan-dev at lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20161115/5fec9343/attachment-0001.html 

From mudokonman at gmail.com  Thu Nov 17 10:10:59 2016
From: mudokonman at gmail.com (William Burns)
Date: Thu, 17 Nov 2016 15:10:59 +0000
Subject: [infinispan-dev] Off-Heap Storage Query
In-Reply-To: <CAJ=bejx5rOgjhyqbCMxDtGxUQDm2ObY+-5LF_+Jg+ohsED4ubw@mail.gmail.com>
References: <CAJ=bejwo9fU9gRZNh8zbpB78O+Wbxtguq8L7JnKAOALRnsRQgw@mail.gmail.com>
	<CA+YCuUOcqBpvmUEeix9KUO626e9uOWWpSqeyhwjr9BaHRyDPLQ@mail.gmail.com>
	<CAJ=bejx5rOgjhyqbCMxDtGxUQDm2ObY+-5LF_+Jg+ohsED4ubw@mail.gmail.com>
Message-ID: <CA+YCuUN4smGOPmhBs1bD3FOE7rvhhumTw=K6dmRJ-h5ewD+HTg@mail.gmail.com>

Answers inline.

On Mon, Nov 14, 2016 at 5:01 PM Alan Kash <crudbug at gmail.com> wrote:

> Thanks Will,
>
> Just another question, does your implementation has JMX integration for
> storage monitoring metrics - Total Bytes / Classes Types / Indexes/ Access
> time etc. ? I am thinking of Classes as buckets.
>

This information will be made available, however the JMX would be exposed
by Infinispan itself.


>
> Is the API designed for generic storage applications. I am thinking what
> Netty did for networking, we can have a similar API abstraction for
> Storage. This will be great for JVM.
>

It is currently tied to our DataContainer API.  It could be changed in the
future though :)


>
>
>
>
>
> On Mon, Nov 14, 2016 at 1:29 PM, William Burns <mudokonman at gmail.com>
> wrote:
>
>
>
> On Mon, Nov 14, 2016 at 12:27 PM Alan Kash <crudbug at gmail.com> wrote:
>
> Hi,
>
> Is there any architecture document of Off-Heap storage architecture. Do we
> have an ETA for this feature.
>
>
> I am planning on creating a PR for this week assuming everything goes
> well.  The required PRs to be integrated before this can go in though are
> still waiting though.
>
> I will be adding official documentation for it soon after.  Just trying to
> get it in at this point.
>
>
> Are we using any standard library for  storage ? I looked online, the
> Apache Cassandra project has abstracted the Off-Heap functionality into
>
>
> No the upcoming implementation is all home grown.  This is the second
> iteration of the implementation, the first used the Netty allocator to
> perform all the various allocations.  However the new implementation is
> 100% off heap using Unsafe for allocations.
>
>
>
> https://github.com/snazy/ohc
>
> Thanks,
> Alan
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20161117/5064e5bb/attachment.html 

From slaskawi at redhat.com  Fri Nov 25 07:32:03 2016
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Fri, 25 Nov 2016 13:32:03 +0100
Subject: [infinispan-dev] Proposal - encrypted cache
Message-ID: <CAA9R9O4a2wh=gU20U4v0akMt40bQg+RPYn=pZW3Kebzn9N7wnw@mail.gmail.com>

Hey!

A while ago I stumbled upon [1]. The article talks about encrypting data
before they reach the server, so that the server doesn't know how to
decrypt it. This makes the data more secure.

The idea is definitely not new and I have been asked about something
similar several times during local JUGs meetups (in my area there are lots
of payments organizations who might be interested in this).

Of course, this can be easily done inside an app, so that it encrypts the
data and passes a byte array to the Hot Rod Client. I'm just thinking about
making it a bit easier and adding a default encryption/decryption mechanism
to the Hot Rod client.

What do you think? Does it make sense?

Thanks
Sebastian

[1] https://eprint.iacr.org/2016/920.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20161125/d5632f62/attachment.html 

From sanne at infinispan.org  Fri Nov 25 08:55:53 2016
From: sanne at infinispan.org (Sanne Grinovero)
Date: Fri, 25 Nov 2016 13:55:53 +0000
Subject: [infinispan-dev] Proposal - encrypted cache
In-Reply-To: <CAA9R9O4a2wh=gU20U4v0akMt40bQg+RPYn=pZW3Kebzn9N7wnw@mail.gmail.com>
References: <CAA9R9O4a2wh=gU20U4v0akMt40bQg+RPYn=pZW3Kebzn9N7wnw@mail.gmail.com>
Message-ID: <CAFm4XO3aC68VONeqpUgcE8aJdNXo4goXO7xwZc=KzWsTE04U+A@mail.gmail.com>

Hi Sebastian,
you're opening a very complex (but interesting!) topic.

As the paper you linked to also reminds, it's extremely hard to
implement such a thing without "giving away" lots of useful metadata
to a potential attacker. It's an interesting paper as they propose a
technique to maintain query capabilities while not having the full
data readability, yet as other papers which I've seen before it's both
complex to implement, and leaves some questions unanswered; in this
case they seem to "just" not being able to camouflage the data access
patterns, which is pretty good but according to some experts really
not enough to keep the decryption keys safe.

The typical problem is that if the server has no clue about the
encrypted blobs at all we won't be able to query it. However there's
ongoing research (like this one?) about being still able to run
queries on behalf of key-owning clients, identify a subset of the
data, e.g. a *naive* example: if you know the data structure and can
tell which section contains the "encrypted surname", then a client
could query for identical matches on the "encrypted surname"; however
this naive approach is critically flawed such as you might be able to
extract the encryption keys by analysing the statistical frequency of
signatures and run a dictionary attack, e.g. you might have a good
guess about which surname is expected to be the most commonly used.
You'll need salting techniques combined within the query capabilities,
e.g. MAC (message authentication codes) but these either require you
to trust the database (are we going in circles?) or expose you to
other forms of attack.

While it's obvious that this introduces some limitations on search
capabilities on the fields of the value, you might also have similar
problems just on the keys. For example you might not be able to use
any form of affinity which takes advantage of some domain specific
knowledge, or just about do anything useful beyond the pure
"key/value" capabilities which are extremely limited.
Besides, even the fact that the "key" doesn't change over time might
be critical: it means you can't use salting on the key, which again
introduces dictionary attacks by merely observing the frequency of
operations.

Even if you're prepared to give up on all those features and accept
some limitations to just encrypt it all on the client, the "grid"
needs nevertheless to be considered a trusted party; given the large
amount of data and access patterns, the data grid has so much insight
on both data and access patterns, that I doubt it can be properly
secured.

I'm not sure we have the right engineering skills to develop such a
system, we'd need at least to brush up on existing research in this
field, of which I'm not aware there being any "full solution" unless
you give a good amount of trust to the database..

I'd love it if someone could explore this more, but be aware that it's
not as easy as just enabling encryption on the client.

Thanks,
Sanne




On 25 November 2016 at 12:32, Sebastian Laskawiec <slaskawi at redhat.com> wrote:
> Hey!
>
> A while ago I stumbled upon [1]. The article talks about encrypting data
> before they reach the server, so that the server doesn't know how to decrypt
> it. This makes the data more secure.
>
> The idea is definitely not new and I have been asked about something similar
> several times during local JUGs meetups (in my area there are lots of
> payments organizations who might be interested in this).
>
> Of course, this can be easily done inside an app, so that it encrypts the
> data and passes a byte array to the Hot Rod Client. I'm just thinking about
> making it a bit easier and adding a default encryption/decryption mechanism
> to the Hot Rod client.
>
> What do you think? Does it make sense?
>
> Thanks
> Sebastian
>
> [1] https://eprint.iacr.org/2016/920.pdf
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

From slaskawi at redhat.com  Mon Nov 28 02:21:56 2016
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Mon, 28 Nov 2016 08:21:56 +0100
Subject: [infinispan-dev] Proposal - encrypted cache
In-Reply-To: <CAFm4XO3aC68VONeqpUgcE8aJdNXo4goXO7xwZc=KzWsTE04U+A@mail.gmail.com>
References: <CAA9R9O4a2wh=gU20U4v0akMt40bQg+RPYn=pZW3Kebzn9N7wnw@mail.gmail.com>
	<CAFm4XO3aC68VONeqpUgcE8aJdNXo4goXO7xwZc=KzWsTE04U+A@mail.gmail.com>
Message-ID: <CAA9R9O4YqfuStSqMVjqj+1ZctExw4ZtKkhpL8e0p5FsOgArP2w@mail.gmail.com>

Hey Sanne!

Comments inlined.

Thanks
Sebastian

On Fri, Nov 25, 2016 at 2:55 PM, Sanne Grinovero <sanne at infinispan.org>
wrote:

> Hi Sebastian,
> you're opening a very complex (but interesting!) topic.
>
> As the paper you linked to also reminds, it's extremely hard to
> implement such a thing without "giving away" lots of useful metadata
> to a potential attacker. It's an interesting paper as they propose a
> technique to maintain query capabilities while not having the full
> data readability, yet as other papers which I've seen before it's both
> complex to implement, and leaves some questions unanswered; in this
> case they seem to "just" not being able to camouflage the data access
> patterns, which is pretty good but according to some experts really
> not enough to keep the decryption keys safe.
>
> The typical problem is that if the server has no clue about the
> encrypted blobs at all we won't be able to query it. However there's
> ongoing research (like this one?) about being still able to run
> queries on behalf of key-owning clients, identify a subset of the
> data, e.g. a *naive* example: if you know the data structure and can
> tell which section contains the "encrypted surname", then a client
> could query for identical matches on the "encrypted surname"; however
> this naive approach is critically flawed such as you might be able to
> extract the encryption keys by analysing the statistical frequency of
> signatures and run a dictionary attack, e.g. you might have a good
> guess about which surname is expected to be the most commonly used.
> You'll need salting techniques combined within the query capabilities,
> e.g. MAC (message authentication codes) but these either require you
> to trust the database (are we going in circles?) or expose you to
> other forms of attack.
>

Yes, you are correct. Not being able to query the server is a very serious
problem. But preventing a potential attacker from analyzing your
communication seems very easy to be solved - just use TLS to encrypt
connection between the client and the server.

So I think the main challenge is how to perform a search operation through
an encrypted data set...


>
> While it's obvious that this introduces some limitations on search
> capabilities on the fields of the value, you might also have similar
> problems just on the keys. For example you might not be able to use
> any form of affinity which takes advantage of some domain specific
> knowledge, or just about do anything useful beyond the pure
> "key/value" capabilities which are extremely limited.
> Besides, even the fact that the "key" doesn't change over time might
> be critical: it means you can't use salting on the key, which again
> introduces dictionary attacks by merely observing the frequency of
> operations.
>
> Even if you're prepared to give up on all those features and accept
> some limitations to just encrypt it all on the client, the "grid"
> needs nevertheless to be considered a trusted party; given the large
> amount of data and access patterns, the data grid has so much insight
> on both data and access patterns, that I doubt it can be properly
> secured.
>

Granted. If a potential attacker had access to the machine hosting an
Infinispan Server (e.g. could do a memory snapshot), the encryption
algorithm would need to "survive" statistical analysis.


>
> I'm not sure we have the right engineering skills to develop such a
> system, we'd need at least to brush up on existing research in this
> field, of which I'm not aware there being any "full solution" unless
> you give a good amount of trust to the database..
>

There's a database called CryptDB:
http://bristolcrypto.blogspot.com/2013/11/how-to-search-on-encrypted-data-in.html

I haven't looked into the research papers yet but if we had to trust any
database we should pick something like that.


>
> I'd love it if someone could explore this more, but be aware that it's
> not as easy as just enabling encryption on the client.
>

I totally agree. Thanks a lot for pointing all those useful aspects!


>
> Thanks,
> Sanne
>
>
>
>
> On 25 November 2016 at 12:32, Sebastian Laskawiec <slaskawi at redhat.com>
> wrote:
> > Hey!
> >
> > A while ago I stumbled upon [1]. The article talks about encrypting data
> > before they reach the server, so that the server doesn't know how to
> decrypt
> > it. This makes the data more secure.
> >
> > The idea is definitely not new and I have been asked about something
> similar
> > several times during local JUGs meetups (in my area there are lots of
> > payments organizations who might be interested in this).
> >
> > Of course, this can be easily done inside an app, so that it encrypts the
> > data and passes a byte array to the Hot Rod Client. I'm just thinking
> about
> > making it a bit easier and adding a default encryption/decryption
> mechanism
> > to the Hot Rod client.
> >
> > What do you think? Does it make sense?
> >
> > Thanks
> > Sebastian
> >
> > [1] https://eprint.iacr.org/2016/920.pdf
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20161128/1f176928/attachment-0001.html 

From slaskawi at redhat.com  Mon Nov 28 07:31:41 2016
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Mon, 28 Nov 2016 13:31:41 +0100
Subject: [infinispan-dev] Spring module - change dependencies to Uber
	Jars
In-Reply-To: <CAH8Ud1EYdWO9e19AJg3=T7kcdSX21kv4m3hV+AoqLs8cdOGJ=w@mail.gmail.com>
References: <CAA9R9O72cC=kxWikU3sseBDqWkpgKfjuLRHonu-sQRfPagyJqA@mail.gmail.com>
	<CAFm4XO3ywbjU68Ny0cvM02YEeOY1i1sr2142VR0ttRvCu9fcpQ@mail.gmail.com>
	<CAFm4XO1TSStKYfDSi+ssd4RpfkonxVBr1MWz0n50E3bCK34w4A@mail.gmail.com>
	<CAH8Ud1EYdWO9e19AJg3=T7kcdSX21kv4m3hV+AoqLs8cdOGJ=w@mail.gmail.com>
Message-ID: <CAA9R9O66y6qDT=voJfkLEFgWr7sDgj6jKuMrU6yYPgwnkbaBHg@mail.gmail.com>

I'm actually on the other side of the table. I really like them!

They are super easy to use - one dependency and off you go. It doesn't
matter whether you use CDI, Query or any other feature - everything is
there.

Of course, there is a price to pay - we need to pull additional
dependencies and relocate packages. But as Tristan once mentioned - it's
only a matter of hammering all the errors out.

On Thu, Nov 3, 2016 at 10:23 AM, Gustavo Fernandes <gustavo at infinispan.org>
wrote:

> On Wed, Nov 2, 2016 at 11:12 PM, Sanne Grinovero <sanne at infinispan.org>
> wrote:
>
>> On 1 February 2016 at 14:12, Sanne Grinovero <sanne at infinispan.org>
>> wrote:
>> > The Uber Jars will always be more problematic than the "small ones" -
>> > as the testsuite doesn't cover them at the same level, if at all - so
>> > I don't think it would be wise to start having components to depend on
>> > them, especially as this looks like it might become viral: what about
>> > other component X that people will want to use with Spring?
>> >
>> > Also when you're deploying on WildFly you probably want to use the
>> > Logger from the application server as it's the one being managed. So
>> > the solution would be wither never use Uber Jars when deploying on the
>> > container, or remove JBoss Logger from the Uber Jars.
>> >
>> > Shall I state once more that the whole Uber Jars affair seems a really
>> > bad idea to me?
>>
>> +1 to myself here :) as we're witnessing again reports of issues with
>> them.
>>
>> Unless someone has a solid explanation about why they are needed,
>> could we start making plans for their deprecation?
>>
>> As far as I remember they were introduced to "reduce the number of
>> dependencies" but this isn't the right way.
>>
>
>
> +1
>
> Having an uber jar is mostly a convenience for those not using a proper
> dependency management
> system or doing quick prototypes, but as soon as we start having several
> uber jars, putting them
> inside osgi bundles and creating jboss modules with them, they become
> really alternate jars and
> a maintenance burden for very little benefit.
>
> Gustavo
>
>
>
>>
>> Thanks,
>> Sanne
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20161128/9b3202c8/attachment.html 

From sanne at infinispan.org  Mon Nov 28 08:18:53 2016
From: sanne at infinispan.org (Sanne Grinovero)
Date: Mon, 28 Nov 2016 13:18:53 +0000
Subject: [infinispan-dev] Spring module - change dependencies to Uber
	Jars
In-Reply-To: <CAA9R9O66y6qDT=voJfkLEFgWr7sDgj6jKuMrU6yYPgwnkbaBHg@mail.gmail.com>
References: <CAA9R9O72cC=kxWikU3sseBDqWkpgKfjuLRHonu-sQRfPagyJqA@mail.gmail.com>
	<CAFm4XO3ywbjU68Ny0cvM02YEeOY1i1sr2142VR0ttRvCu9fcpQ@mail.gmail.com>
	<CAFm4XO1TSStKYfDSi+ssd4RpfkonxVBr1MWz0n50E3bCK34w4A@mail.gmail.com>
	<CAH8Ud1EYdWO9e19AJg3=T7kcdSX21kv4m3hV+AoqLs8cdOGJ=w@mail.gmail.com>
	<CAA9R9O66y6qDT=voJfkLEFgWr7sDgj6jKuMrU6yYPgwnkbaBHg@mail.gmail.com>
Message-ID: <CAFm4XO1YAQC=x6Rijs0CNnnWNzT4AN7UNBb8O9KPxdCBDVZoQA@mail.gmail.com>

There are some benefits to it, but it gets extremely tricky and nasty
for end users if they happen to get duplicates of any of our
libraries, or dependencies.

I think the worst problem being that they "sneak in" unexpectedly as
Maven doesn't deal nicely with such situations, and the error messages
one gets are both scary and counter-intuitive.

Maybe we could alleviate for this problem by e.g. testing that some
resources are unique on the classpath? For example, add a marker file
in the infinispan-core.jar and a different marker in the uber jar,
then verify there's a strict either/or of each dependency instance.

FWI I'm confident that the current "benefits" far outweigh all the
problems these introduce, unless you can all spend some time on polish
those errors, and make sure the examples and docs are very clear about
either/or situations, I'd rather drop them.

Thanks,
Sanne

On 28 November 2016 at 12:31, Sebastian Laskawiec <slaskawi at redhat.com> wrote:
> I'm actually on the other side of the table. I really like them!
>
> They are super easy to use - one dependency and off you go. It doesn't
> matter whether you use CDI, Query or any other feature - everything is
> there.
>
> Of course, there is a price to pay - we need to pull additional dependencies
> and relocate packages. But as Tristan once mentioned - it's only a matter of
> hammering all the errors out.
>
> On Thu, Nov 3, 2016 at 10:23 AM, Gustavo Fernandes <gustavo at infinispan.org>
> wrote:
>>
>> On Wed, Nov 2, 2016 at 11:12 PM, Sanne Grinovero <sanne at infinispan.org>
>> wrote:
>>>
>>> On 1 February 2016 at 14:12, Sanne Grinovero <sanne at infinispan.org>
>>> wrote:
>>> > The Uber Jars will always be more problematic than the "small ones" -
>>> > as the testsuite doesn't cover them at the same level, if at all - so
>>> > I don't think it would be wise to start having components to depend on
>>> > them, especially as this looks like it might become viral: what about
>>> > other component X that people will want to use with Spring?
>>> >
>>> > Also when you're deploying on WildFly you probably want to use the
>>> > Logger from the application server as it's the one being managed. So
>>> > the solution would be wither never use Uber Jars when deploying on the
>>> > container, or remove JBoss Logger from the Uber Jars.
>>> >
>>> > Shall I state once more that the whole Uber Jars affair seems a really
>>> > bad idea to me?
>>>
>>> +1 to myself here :) as we're witnessing again reports of issues with
>>> them.
>>>
>>> Unless someone has a solid explanation about why they are needed,
>>> could we start making plans for their deprecation?
>>>
>>> As far as I remember they were introduced to "reduce the number of
>>> dependencies" but this isn't the right way.
>>
>>
>>
>> +1
>>
>> Having an uber jar is mostly a convenience for those not using a proper
>> dependency management
>> system or doing quick prototypes, but as soon as we start having several
>> uber jars, putting them
>> inside osgi bundles and creating jboss modules with them, they become
>> really alternate jars and
>> a maintenance burden for very little benefit.
>>
>> Gustavo
>>
>>
>>>
>>>
>>> Thanks,
>>> Sanne
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

From sanne at infinispan.org  Mon Nov 28 10:07:12 2016
From: sanne at infinispan.org (Sanne Grinovero)
Date: Mon, 28 Nov 2016 15:07:12 +0000
Subject: [infinispan-dev] Proposal - encrypted cache
In-Reply-To: <CAA9R9O4YqfuStSqMVjqj+1ZctExw4ZtKkhpL8e0p5FsOgArP2w@mail.gmail.com>
References: <CAA9R9O4a2wh=gU20U4v0akMt40bQg+RPYn=pZW3Kebzn9N7wnw@mail.gmail.com>
	<CAFm4XO3aC68VONeqpUgcE8aJdNXo4goXO7xwZc=KzWsTE04U+A@mail.gmail.com>
	<CAA9R9O4YqfuStSqMVjqj+1ZctExw4ZtKkhpL8e0p5FsOgArP2w@mail.gmail.com>
Message-ID: <CAFm4XO1_5WjWy3oS_R+Hp5H5MZ1ggQYXWZ17FF_vWO8_26dHsg@mail.gmail.com>

On 28 November 2016 at 07:21, Sebastian Laskawiec <slaskawi at redhat.com> wrote:
> Hey Sanne!
>
> Comments inlined.
>
> Thanks
> Sebastian
>
> On Fri, Nov 25, 2016 at 2:55 PM, Sanne Grinovero <sanne at infinispan.org>
> wrote:
>>
>> Hi Sebastian,
>> you're opening a very complex (but interesting!) topic.
>>
>> As the paper you linked to also reminds, it's extremely hard to
>> implement such a thing without "giving away" lots of useful metadata
>> to a potential attacker. It's an interesting paper as they propose a
>> technique to maintain query capabilities while not having the full
>> data readability, yet as other papers which I've seen before it's both
>> complex to implement, and leaves some questions unanswered; in this
>> case they seem to "just" not being able to camouflage the data access
>> patterns, which is pretty good but according to some experts really
>> not enough to keep the decryption keys safe.
>>
>> The typical problem is that if the server has no clue about the
>> encrypted blobs at all we won't be able to query it. However there's
>> ongoing research (like this one?) about being still able to run
>> queries on behalf of key-owning clients, identify a subset of the
>> data, e.g. a *naive* example: if you know the data structure and can
>> tell which section contains the "encrypted surname", then a client
>> could query for identical matches on the "encrypted surname"; however
>> this naive approach is critically flawed such as you might be able to
>> extract the encryption keys by analysing the statistical frequency of
>> signatures and run a dictionary attack, e.g. you might have a good
>> guess about which surname is expected to be the most commonly used.
>> You'll need salting techniques combined within the query capabilities,
>> e.g. MAC (message authentication codes) but these either require you
>> to trust the database (are we going in circles?) or expose you to
>> other forms of attack.
>
>
> Yes, you are correct. Not being able to query the server is a very serious
> problem. But preventing a potential attacker from analyzing your
> communication seems very easy to be solved - just use TLS to encrypt
> connection between the client and the server.

Maybe I misunderstood the "requirements" of your proposal. My answer
was based on the assumption that the client wouldn't trust the
servers, for example a client wanting to store sensible data in a
"database as a service" platform, having a third party provide the
service.
If you use TLS during communication, it implies you don't trust the
communication channels but somewhat trust the server. You might as
well just use TLS and then not store the data in encrypted form, or
share the encryption access with the servers?

Thanks,
Sanne


>
> So I think the main challenge is how to perform a search operation through
> an encrypted data set...
>
>>
>>
>> While it's obvious that this introduces some limitations on search
>> capabilities on the fields of the value, you might also have similar
>> problems just on the keys. For example you might not be able to use
>> any form of affinity which takes advantage of some domain specific
>> knowledge, or just about do anything useful beyond the pure
>> "key/value" capabilities which are extremely limited.
>> Besides, even the fact that the "key" doesn't change over time might
>> be critical: it means you can't use salting on the key, which again
>> introduces dictionary attacks by merely observing the frequency of
>> operations.
>>
>> Even if you're prepared to give up on all those features and accept
>> some limitations to just encrypt it all on the client, the "grid"
>> needs nevertheless to be considered a trusted party; given the large
>> amount of data and access patterns, the data grid has so much insight
>> on both data and access patterns, that I doubt it can be properly
>> secured.
>
>
> Granted. If a potential attacker had access to the machine hosting an
> Infinispan Server (e.g. could do a memory snapshot), the encryption
> algorithm would need to "survive" statistical analysis.
>
>>
>>
>> I'm not sure we have the right engineering skills to develop such a
>> system, we'd need at least to brush up on existing research in this
>> field, of which I'm not aware there being any "full solution" unless
>> you give a good amount of trust to the database..
>
>
> There's a database called CryptDB:
> http://bristolcrypto.blogspot.com/2013/11/how-to-search-on-encrypted-data-in.html
>
> I haven't looked into the research papers yet but if we had to trust any
> database we should pick something like that.
>
>>
>>
>> I'd love it if someone could explore this more, but be aware that it's
>> not as easy as just enabling encryption on the client.
>
>
> I totally agree. Thanks a lot for pointing all those useful aspects!
>
>>
>>
>> Thanks,
>> Sanne
>>
>>
>>
>>
>> On 25 November 2016 at 12:32, Sebastian Laskawiec <slaskawi at redhat.com>
>> wrote:
>> > Hey!
>> >
>> > A while ago I stumbled upon [1]. The article talks about encrypting data
>> > before they reach the server, so that the server doesn't know how to
>> > decrypt
>> > it. This makes the data more secure.
>> >
>> > The idea is definitely not new and I have been asked about something
>> > similar
>> > several times during local JUGs meetups (in my area there are lots of
>> > payments organizations who might be interested in this).
>> >
>> > Of course, this can be easily done inside an app, so that it encrypts
>> > the
>> > data and passes a byte array to the Hot Rod Client. I'm just thinking
>> > about
>> > making it a bit easier and adding a default encryption/decryption
>> > mechanism
>> > to the Hot Rod client.
>> >
>> > What do you think? Does it make sense?
>> >
>> > Thanks
>> > Sebastian
>> >
>> > [1] https://eprint.iacr.org/2016/920.pdf
>> >
>> > _______________________________________________
>> > infinispan-dev mailing list
>> > infinispan-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

From slaskawi at redhat.com  Tue Nov 29 04:24:54 2016
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Tue, 29 Nov 2016 10:24:54 +0100
Subject: [infinispan-dev] Proposal - encrypted cache
In-Reply-To: <CAFm4XO1_5WjWy3oS_R+Hp5H5MZ1ggQYXWZ17FF_vWO8_26dHsg@mail.gmail.com>
References: <CAA9R9O4a2wh=gU20U4v0akMt40bQg+RPYn=pZW3Kebzn9N7wnw@mail.gmail.com>
	<CAFm4XO3aC68VONeqpUgcE8aJdNXo4goXO7xwZc=KzWsTE04U+A@mail.gmail.com>
	<CAA9R9O4YqfuStSqMVjqj+1ZctExw4ZtKkhpL8e0p5FsOgArP2w@mail.gmail.com>
	<CAFm4XO1_5WjWy3oS_R+Hp5H5MZ1ggQYXWZ17FF_vWO8_26dHsg@mail.gmail.com>
Message-ID: <CAA9R9O7mSDti4bND28paAxDHHMGmvW8gVh=nT=y-tPeWyf4Q9g@mail.gmail.com>

With your explanation I think I get it now...

So from my point of view, I would assume that we *can't* trust the servers.
But with TLS we *can* trust the communication channel.

Does this makes sense now?

On Mon, Nov 28, 2016 at 4:07 PM, Sanne Grinovero <sanne at infinispan.org>
wrote:

> On 28 November 2016 at 07:21, Sebastian Laskawiec <slaskawi at redhat.com>
> wrote:
> > Hey Sanne!
> >
> > Comments inlined.
> >
> > Thanks
> > Sebastian
> >
> > On Fri, Nov 25, 2016 at 2:55 PM, Sanne Grinovero <sanne at infinispan.org>
> > wrote:
> >>
> >> Hi Sebastian,
> >> you're opening a very complex (but interesting!) topic.
> >>
> >> As the paper you linked to also reminds, it's extremely hard to
> >> implement such a thing without "giving away" lots of useful metadata
> >> to a potential attacker. It's an interesting paper as they propose a
> >> technique to maintain query capabilities while not having the full
> >> data readability, yet as other papers which I've seen before it's both
> >> complex to implement, and leaves some questions unanswered; in this
> >> case they seem to "just" not being able to camouflage the data access
> >> patterns, which is pretty good but according to some experts really
> >> not enough to keep the decryption keys safe.
> >>
> >> The typical problem is that if the server has no clue about the
> >> encrypted blobs at all we won't be able to query it. However there's
> >> ongoing research (like this one?) about being still able to run
> >> queries on behalf of key-owning clients, identify a subset of the
> >> data, e.g. a *naive* example: if you know the data structure and can
> >> tell which section contains the "encrypted surname", then a client
> >> could query for identical matches on the "encrypted surname"; however
> >> this naive approach is critically flawed such as you might be able to
> >> extract the encryption keys by analysing the statistical frequency of
> >> signatures and run a dictionary attack, e.g. you might have a good
> >> guess about which surname is expected to be the most commonly used.
> >> You'll need salting techniques combined within the query capabilities,
> >> e.g. MAC (message authentication codes) but these either require you
> >> to trust the database (are we going in circles?) or expose you to
> >> other forms of attack.
> >
> >
> > Yes, you are correct. Not being able to query the server is a very
> serious
> > problem. But preventing a potential attacker from analyzing your
> > communication seems very easy to be solved - just use TLS to encrypt
> > connection between the client and the server.
>
> Maybe I misunderstood the "requirements" of your proposal. My answer
> was based on the assumption that the client wouldn't trust the
> servers, for example a client wanting to store sensible data in a
> "database as a service" platform, having a third party provide the
> service.
> If you use TLS during communication, it implies you don't trust the
> communication channels but somewhat trust the server. You might as
> well just use TLS and then not store the data in encrypted form, or
> share the encryption access with the servers?
>
> Thanks,
> Sanne
>
>
> >
> > So I think the main challenge is how to perform a search operation
> through
> > an encrypted data set...
> >
> >>
> >>
> >> While it's obvious that this introduces some limitations on search
> >> capabilities on the fields of the value, you might also have similar
> >> problems just on the keys. For example you might not be able to use
> >> any form of affinity which takes advantage of some domain specific
> >> knowledge, or just about do anything useful beyond the pure
> >> "key/value" capabilities which are extremely limited.
> >> Besides, even the fact that the "key" doesn't change over time might
> >> be critical: it means you can't use salting on the key, which again
> >> introduces dictionary attacks by merely observing the frequency of
> >> operations.
> >>
> >> Even if you're prepared to give up on all those features and accept
> >> some limitations to just encrypt it all on the client, the "grid"
> >> needs nevertheless to be considered a trusted party; given the large
> >> amount of data and access patterns, the data grid has so much insight
> >> on both data and access patterns, that I doubt it can be properly
> >> secured.
> >
> >
> > Granted. If a potential attacker had access to the machine hosting an
> > Infinispan Server (e.g. could do a memory snapshot), the encryption
> > algorithm would need to "survive" statistical analysis.
> >
> >>
> >>
> >> I'm not sure we have the right engineering skills to develop such a
> >> system, we'd need at least to brush up on existing research in this
> >> field, of which I'm not aware there being any "full solution" unless
> >> you give a good amount of trust to the database..
> >
> >
> > There's a database called CryptDB:
> > http://bristolcrypto.blogspot.com/2013/11/how-to-search-on-
> encrypted-data-in.html
> >
> > I haven't looked into the research papers yet but if we had to trust any
> > database we should pick something like that.
> >
> >>
> >>
> >> I'd love it if someone could explore this more, but be aware that it's
> >> not as easy as just enabling encryption on the client.
> >
> >
> > I totally agree. Thanks a lot for pointing all those useful aspects!
> >
> >>
> >>
> >> Thanks,
> >> Sanne
> >>
> >>
> >>
> >>
> >> On 25 November 2016 at 12:32, Sebastian Laskawiec <slaskawi at redhat.com>
> >> wrote:
> >> > Hey!
> >> >
> >> > A while ago I stumbled upon [1]. The article talks about encrypting
> data
> >> > before they reach the server, so that the server doesn't know how to
> >> > decrypt
> >> > it. This makes the data more secure.
> >> >
> >> > The idea is definitely not new and I have been asked about something
> >> > similar
> >> > several times during local JUGs meetups (in my area there are lots of
> >> > payments organizations who might be interested in this).
> >> >
> >> > Of course, this can be easily done inside an app, so that it encrypts
> >> > the
> >> > data and passes a byte array to the Hot Rod Client. I'm just thinking
> >> > about
> >> > making it a bit easier and adding a default encryption/decryption
> >> > mechanism
> >> > to the Hot Rod client.
> >> >
> >> > What do you think? Does it make sense?
> >> >
> >> > Thanks
> >> > Sebastian
> >> >
> >> > [1] https://eprint.iacr.org/2016/920.pdf
> >> >
> >> > _______________________________________________
> >> > infinispan-dev mailing list
> >> > infinispan-dev at lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
> >
> >
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20161129/3576c506/attachment-0001.html 

From slaskawi at redhat.com  Wed Nov 30 04:33:42 2016
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Wed, 30 Nov 2016 10:33:42 +0100
Subject: [infinispan-dev] Spring module - change dependencies to Uber
	Jars
In-Reply-To: <CAA9R9O4WZ79jsV7+9Vx2c0T2YTm-aCQFjGCSGkKXxi0x1_Vb8A@mail.gmail.com>
References: <CAA9R9O72cC=kxWikU3sseBDqWkpgKfjuLRHonu-sQRfPagyJqA@mail.gmail.com>
	<CAFm4XO3ywbjU68Ny0cvM02YEeOY1i1sr2142VR0ttRvCu9fcpQ@mail.gmail.com>
	<CAA9R9O7eOkT9wA+iX7Sem7z4cLi8-ha-8A-7jsrp9dpOjtAZ3w@mail.gmail.com>
	<CAA9R9O6H9wZcivTYVz4+CKxKkgrafm3uWAVk8x2oBf76YF4Ntg@mail.gmail.com>
	<CAA9R9O4WZ79jsV7+9Vx2c0T2YTm-aCQFjGCSGkKXxi0x1_Vb8A@mail.gmail.com>
Message-ID: <CAA9R9O5uxwUNUWpFazgpHPs3mpUFmnn_QTHCg7v5RxeA96njBw@mail.gmail.com>

Hey guys!

Just FYI - recently I was thinking about putting Spring integration modules
inside uber jars [1].

This could potentially lower the number of dependencies for our clients
(they would just need Spring (either Boot or standard jars) and
infinispan-embedded to get going) however after a longer thought I decided
to kill this idea. The main reason is that placing both infinispan-embedded
and infinispan-spring4-embedded would result in duplicated classes on the
classpath. And this might cause many weird errors. I documented it in my
comment [2].

Please let me know if you have any other thoughts and comments regarding
this...

Thanks
Sebastian

[1] https://issues.jboss.org/browse/ISPN-7237
[2]
https://issues.jboss.org/browse/ISPN-7237?focusedCommentId=13331339#comment-13331339

On Thu, Feb 25, 2016 at 2:43 PM, Sebastian Laskawiec <slaskawi at redhat.com>
wrote:

> Implemented: https://github.com/infinispan/infinispan/pull/4039
>
> Thanks
> Sebastian
>
> On Wed, Feb 3, 2016 at 3:11 PM, Sebastian Laskawiec <slaskawi at redhat.com>
> wrote:
>
>> During our talk on IRC Tristan proposed to mark Spring dependencies as
>> provided. Another similar approach would be to make them optional.
>>
>> I think both approaches are even better than making Spring module depend
>> on Uber Jars. However there is a price to pay - each user will probably
>> have to declare in his pom what dependencies he'd like to use (uber or
>> small jars).
>>
>> On Tue, Feb 2, 2016 at 7:53 AM, Sebastian Laskawiec <slaskawi at redhat.com>
>> wrote:
>>
>>> I think the plan is to cover more integration tests (if not all) with
>>> Uber Jars - right Martin?
>>>
>>> WRT the logger - yes you are absolutely correct and that's why logger
>>> implementations are excluded from Uber Jars (Ubers contain only APIs - like
>>> SLF4J-API or LOG4J-API).
>>>
>>> I think the uber jar vs small jar is more about what configurations are
>>> preferred. Note that you can always (even now) exclude all dependencies
>>> from Spring Remote and add Remote Uber Jar manually. Switching Spring
>>> Remote module to Uber Jars will only change the default behavior (we will
>>> still be able to exclude dependencies and add small jars if you prefer
>>> them).
>>> If we proceed with this change - of course I will document this
>>> excluding part in the docs (currently it is not written anywhere and it is
>>> not-so-obvious solution).
>>>
>>> On Mon, Feb 1, 2016 at 3:12 PM, Sanne Grinovero <sanne at infinispan.org>
>>> wrote:
>>>
>>>> The Uber Jars will always be more problematic than the "small ones" -
>>>> as the testsuite doesn't cover them at the same level, if at all - so
>>>> I don't think it would be wise to start having components to depend on
>>>> them, especially as this looks like it might become viral: what about
>>>> other component X that people will want to use with Spring?
>>>>
>>>> Also when you're deploying on WildFly you probably want to use the
>>>> Logger from the application server as it's the one being managed. So
>>>> the solution would be wither never use Uber Jars when deploying on the
>>>> container, or remove JBoss Logger from the Uber Jars.
>>>>
>>>> Shall I state once more that the whole Uber Jars affair seems a really
>>>> bad idea to me?
>>>>
>>>> Thanks,
>>>> Sanne
>>>>
>>>>
>>>>
>>>> On 1 February 2016 at 11:31, Sebastian Laskawiec <slaskawi at redhat.com>
>>>> wrote:
>>>> > Hey!
>>>> >
>>>> > I'm currently trying to solve a tricky class loading issue connected
>>>> to
>>>> > Spring, CDI and Uber Jars. Here's the scenario:
>>>> >
>>>> > Remote Uber Jar contains CDI module
>>>> > Our Hot Rod client use newer version of JBoss Logging which is
>>>> present in
>>>> > Wildfly/EAP modules
>>>> > However EAP and Wildfly will load (and make available for deployment)
>>>> their
>>>> > own version of JBoss Logging [1]
>>>> >
>>>> > The easiest fix for this is to relocate JBoss Logging package in Uber
>>>> Jar
>>>> >
>>>> > Spring module requires some classes from Infinispan Common and they
>>>> in turn
>>>> > need BasicLogger from JBoss Logging
>>>> >
>>>> > If we relocate JBoss Logging and will try to use Uber Jar with Spring
>>>> - we
>>>> > will end up with classloading issue [2]
>>>> >
>>>> > So it seems the best approach is to make Spring depend on Uber Jars
>>>> instead
>>>> > of "small ones". Of course, users who use small jars will probably be
>>>> > affected by this change (they would have to either accept using Uber
>>>> Jars or
>>>> > exclude them in their poms and add dependencies manually).
>>>> >
>>>> > Is anyone against this solution? JIRA tracking ticket: [3].
>>>> >
>>>> > Thanks
>>>> > Sebastian
>>>> >
>>>> > [1] Scenario with Weld enabled WAR
>>>> > https://docs.jboss.org/author/display/AS7/Implicit+module+
>>>> dependencies+for+deployments
>>>> > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1266831#c7
>>>> > [3] https://issues.jboss.org/browse/ISPN-6132
>>>> >
>>>> > _______________________________________________
>>>> > infinispan-dev mailing list
>>>> > infinispan-dev at lists.jboss.org
>>>> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20161130/f7e2ae86/attachment.html 

From ttarrant at redhat.com  Wed Nov 30 09:13:54 2016
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Wed, 30 Nov 2016 15:13:54 +0100
Subject: [infinispan-dev] Default cache
In-Reply-To: <CAF5qqoMHF=k3h=qYMwrER1V4q0MkH72B=a3kKUdbzvpsfGUw0A@mail.gmail.com>
References: <6664a2bc-a7aa-4fbb-4386-76916d2f6813@redhat.com>
	<CAF5qqoMHF=k3h=qYMwrER1V4q0MkH72B=a3kKUdbzvpsfGUw0A@mail.gmail.com>
Message-ID: <53632d56-e75b-13c8-5d6f-1ad61f5dddc0@redhat.com>

Some additional notes:

- currently the XSD specifies the default-cache attribute on the 
cache-container element as required, but the parser doesn't enforce it.
- A default ConfigurationBuilder is created for the default cache if one 
has not been specified

My questions:

1. do we want the default cache to be optional or actually require it in 
the declarative configuration ?

** A: no enforcement. In this case requesting the default cache should 
print a warning about falling back to a "default" empty configuration.

** B: we don't require the user to specify a default cache in the 
configuration, but invoking getCache() will throw an exception.

** C: enforce it, although this will break all those XML files who 
haven't specified it.

My preference is to use the namespace version and go for the A approach 
for < 9.0 and the B approach otherwise.

2. currently, requesting a named cache for which a configuration hasn't 
been defined implicitly creates the cache by using the default 
configuration as a template.

** A: continue as is

** B: continue to implicitly create a cache, but use an empty 
configuration instead of using the default configuration, as this has 
been the source of confusion among users. Also print a warning.

** C: do not create caches unless a configuration has been explicitly 
provided.

My preference is to use the namespace version and go for the A approach 
for < 9.0 and the C approach otherwise.

Unfortunately the namespace version trick doesn't work for programmatic 
configurations. Probably we should add a boolean flag on the 
GlobalConfigurationManager (e.g. implicitCacheCreation) which defaults 
to false (because that's the "new order") but allows switching to the 
old behaviour if needed.

In any case I'd like to also introduce a JCache-like createCache() API

Tristan

On 10/11/16 13:20, Paul Ferraro wrote:
> +1000
>
> This is precisely how we've setup cache manager semantics in WildFly
> (since AS7):
> https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/spi/src/main/java/org/wildfly/clustering/infinispan/spi/CacheContainer.java
> https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/extension/src/main/java/org/jboss/as/clustering/infinispan/DefaultCacheContainer.java
>
> I'd love to be able to drop this.
>
> Paul
>
> On Thu, Nov 10, 2016 at 3:38 AM, Tristan Tarrant <ttarrant at redhat.com> wrote:
>> In the discussion for [1] the subject of the default cache and the way
>> it affects configuration inheritance came up.
>>
>> My proposal is:
>> - remove the default cache as a special cache altogether
>> - CacheManager.getCache()  should return the named cache specified as
>> default in the configuration.
>> - the programmatic GlobalConfigurationBuilder/GlobalConfiguration should
>> have the notion of the default named cache (currently this is handled in
>> the parser)
>> - Retrieving the cache named "___defaultcache" should actually retrieve
>> the above named cache
>>
>> Opinions ?
>>
>> Tristan
>>
>> [1] https://github.com/infinispan/infinispan/pull/4631
>> --
>> Tristan Tarrant
>> Infinispan Lead
>> JBoss, a division of Red Hat
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat

From slaskawi at redhat.com  Wed Nov 30 10:24:04 2016
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Wed, 30 Nov 2016 16:24:04 +0100
Subject: [infinispan-dev] Default cache
In-Reply-To: <53632d56-e75b-13c8-5d6f-1ad61f5dddc0@redhat.com>
References: <6664a2bc-a7aa-4fbb-4386-76916d2f6813@redhat.com>
	<CAF5qqoMHF=k3h=qYMwrER1V4q0MkH72B=a3kKUdbzvpsfGUw0A@mail.gmail.com>
	<53632d56-e75b-13c8-5d6f-1ad61f5dddc0@redhat.com>
Message-ID: <CAA9R9O7EvKKYH8GOVKiKXfegK4L30bnhcetjP8CL90AQGCUmGQ@mail.gmail.com>

Hey Tristan,

Comments inlined.

Thanks
Sebastian

On Wed, Nov 30, 2016 at 3:13 PM, Tristan Tarrant <ttarrant at redhat.com>
wrote:

> Some additional notes:
>
> - currently the XSD specifies the default-cache attribute on the
> cache-container element as required, but the parser doesn't enforce it.
> - A default ConfigurationBuilder is created for the default cache if one
> has not been specified
>
> My questions:
>
> 1. do we want the default cache to be optional or actually require it in
> the declarative configuration ?
>
> ** A: no enforcement. In this case requesting the default cache should
> print a warning about falling back to a "default" empty configuration.
>
> ** B: we don't require the user to specify a default cache in the
> configuration, but invoking getCache() will throw an exception.
>
> ** C: enforce it, although this will break all those XML files who
> haven't specified it.
>
> My preference is to use the namespace version and go for the A approach
> for < 9.0 and the B approach otherwise.
>

I generally don't like the option B, since it frustrates developers and it
might make the 8.x -> 9.x migration painful.

However I really like your proposal for a GlobalConfigurationManager
with implicitCacheCreation. However I would set it to true as our default.
Effectively this would results in option A being implemented (somewhat).


>
> 2. currently, requesting a named cache for which a configuration hasn't
> been defined implicitly creates the cache by using the default
> configuration as a template.
>
> ** A: continue as is
>
> ** B: continue to implicitly create a cache, but use an empty
> configuration instead of using the default configuration, as this has
> been the source of confusion among users. Also print a warning.
>
> ** C: do not create caches unless a configuration has been explicitly
> provided.
>
> My preference is to use the namespace version and go for the A approach
> for < 9.0 and the C approach otherwise.
>
> Unfortunately the namespace version trick doesn't work for programmatic
> configurations. Probably we should add a boolean flag on the
> GlobalConfigurationManager (e.g. implicitCacheCreation) which defaults
> to false (because that's the "new order") but allows switching to the
> old behaviour if needed.
>

Again A. The same arguments as the above.


>
> In any case I'd like to also introduce a JCache-like createCache() API
>
> Tristan
>
> On 10/11/16 13:20, Paul Ferraro wrote:
> > +1000
> >
> > This is precisely how we've setup cache manager semantics in WildFly
> > (since AS7):
> > https://github.com/wildfly/wildfly/blob/master/
> clustering/infinispan/spi/src/main/java/org/wildfly/
> clustering/infinispan/spi/CacheContainer.java
> > https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/
> extension/src/main/java/org/jboss/as/clustering/infinispan/
> DefaultCacheContainer.java
> >
> > I'd love to be able to drop this.
> >
> > Paul
> >
> > On Thu, Nov 10, 2016 at 3:38 AM, Tristan Tarrant <ttarrant at redhat.com>
> wrote:
> >> In the discussion for [1] the subject of the default cache and the way
> >> it affects configuration inheritance came up.
> >>
> >> My proposal is:
> >> - remove the default cache as a special cache altogether
> >> - CacheManager.getCache()  should return the named cache specified as
> >> default in the configuration.
> >> - the programmatic GlobalConfigurationBuilder/GlobalConfiguration
> should
> >> have the notion of the default named cache (currently this is handled in
> >> the parser)
> >> - Retrieving the cache named "___defaultcache" should actually retrieve
> >> the above named cache
> >>
> >> Opinions ?
> >>
> >> Tristan
> >>
> >> [1] https://github.com/infinispan/infinispan/pull/4631
> >> --
> >> Tristan Tarrant
> >> Infinispan Lead
> >> JBoss, a division of Red Hat
> >> _______________________________________________
> >> infinispan-dev mailing list
> >> infinispan-dev at lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> > _______________________________________________
> > infinispan-dev mailing list
> > infinispan-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> >
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20161130/86c8daa6/attachment-0001.html 

From paul.ferraro at redhat.com  Wed Nov 30 11:44:26 2016
From: paul.ferraro at redhat.com (Paul Ferraro)
Date: Wed, 30 Nov 2016 11:44:26 -0500
Subject: [infinispan-dev] Default cache
In-Reply-To: <53632d56-e75b-13c8-5d6f-1ad61f5dddc0@redhat.com>
References: <6664a2bc-a7aa-4fbb-4386-76916d2f6813@redhat.com>
	<CAF5qqoMHF=k3h=qYMwrER1V4q0MkH72B=a3kKUdbzvpsfGUw0A@mail.gmail.com>
	<53632d56-e75b-13c8-5d6f-1ad61f5dddc0@redhat.com>
Message-ID: <CAF5qqoNHmjEB9N6gwYSGh=hvZLE-ECEgJRV4adnyjuRmF_WFeg@mail.gmail.com>

On Wed, Nov 30, 2016 at 9:13 AM, Tristan Tarrant <ttarrant at redhat.com> wrote:
> Some additional notes:
>
> - currently the XSD specifies the default-cache attribute on the
> cache-container element as required, but the parser doesn't enforce it.
> - A default ConfigurationBuilder is created for the default cache if one
> has not been specified
>
> My questions:
>
> 1. do we want the default cache to be optional or actually require it in
> the declarative configuration ?

In WildFly, default-cache has been optional since WF8.  The
cache-container used for hibernate 2LC, for example, does not have any
concept of a default-cache.  So, for us anyway, it makes sense for
default-cache to be optional.  However, we have the luxury of falling
back to Infinispan's default getCache() logic in the event that no
default-cache was specified.

> ** A: no enforcement. In this case requesting the default cache should
> print a warning about falling back to a "default" empty configuration.
>
> ** B: we don't require the user to specify a default cache in the
> configuration, but invoking getCache() will throw an exception.
>
> ** C: enforce it, although this will break all those XML files who
> haven't specified it.
>
> My preference is to use the namespace version and go for the A approach
> for < 9.0 and the B approach otherwise.

I think that makes sense.

> 2. currently, requesting a named cache for which a configuration hasn't
> been defined implicitly creates the cache by using the default
> configuration as a template.
>
> ** A: continue as is
>
> ** B: continue to implicitly create a cache, but use an empty
> configuration instead of using the default configuration, as this has
> been the source of confusion among users. Also print a warning.
>
> ** C: do not create caches unless a configuration has been explicitly
> provided.
>
> My preference is to use the namespace version and go for the A approach
> for < 9.0 and the C approach otherwise.

Agreed.

> Unfortunately the namespace version trick doesn't work for programmatic
> configurations. Probably we should add a boolean flag on the
> GlobalConfigurationManager (e.g. implicitCacheCreation) which defaults
> to false (because that's the "new order") but allows switching to the
> old behaviour if needed.
>
> In any case I'd like to also introduce a JCache-like createCache() API

I think it would be best/cleanest if caches created via this API are
anonymous (i.e. not managed by the cache manager or made accessible
via getCache(String)).  That way there is no ambiguity about who is
meant to manage the lifecycle (user vs container).

> Tristan
>
> On 10/11/16 13:20, Paul Ferraro wrote:
>> +1000
>>
>> This is precisely how we've setup cache manager semantics in WildFly
>> (since AS7):
>> https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/spi/src/main/java/org/wildfly/clustering/infinispan/spi/CacheContainer.java
>> https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/extension/src/main/java/org/jboss/as/clustering/infinispan/DefaultCacheContainer.java
>>
>> I'd love to be able to drop this.
>>
>> Paul
>>
>> On Thu, Nov 10, 2016 at 3:38 AM, Tristan Tarrant <ttarrant at redhat.com> wrote:
>>> In the discussion for [1] the subject of the default cache and the way
>>> it affects configuration inheritance came up.
>>>
>>> My proposal is:
>>> - remove the default cache as a special cache altogether
>>> - CacheManager.getCache()  should return the named cache specified as
>>> default in the configuration.
>>> - the programmatic GlobalConfigurationBuilder/GlobalConfiguration should
>>> have the notion of the default named cache (currently this is handled in
>>> the parser)
>>> - Retrieving the cache named "___defaultcache" should actually retrieve
>>> the above named cache
>>>
>>> Opinions ?
>>>
>>> Tristan
>>>
>>> [1] https://github.com/infinispan/infinispan/pull/4631
>>> --
>>> Tristan Tarrant
>>> Infinispan Lead
>>> JBoss, a division of Red Hat
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

From ttarrant at redhat.com  Wed Nov 30 12:41:02 2016
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Wed, 30 Nov 2016 18:41:02 +0100
Subject: [infinispan-dev] Default cache
In-Reply-To: <CAF5qqoNHmjEB9N6gwYSGh=hvZLE-ECEgJRV4adnyjuRmF_WFeg@mail.gmail.com>
References: <6664a2bc-a7aa-4fbb-4386-76916d2f6813@redhat.com>
	<CAF5qqoMHF=k3h=qYMwrER1V4q0MkH72B=a3kKUdbzvpsfGUw0A@mail.gmail.com>
	<53632d56-e75b-13c8-5d6f-1ad61f5dddc0@redhat.com>
	<CAF5qqoNHmjEB9N6gwYSGh=hvZLE-ECEgJRV4adnyjuRmF_WFeg@mail.gmail.com>
Message-ID: <a9d82e63-089b-636e-86eb-5322c9350632@redhat.com>

On 30/11/16 17:44, Paul Ferraro wrote:
> On Wed, Nov 30, 2016 at 9:13 AM, Tristan Tarrant <ttarrant at redhat.com> wrote:
>> Some additional notes:
>>
>> - currently the XSD specifies the default-cache attribute on the
>> cache-container element as required, but the parser doesn't enforce it.
>> - A default ConfigurationBuilder is created for the default cache if one
>> has not been specified
>>
>> My questions:
>>
>> 1. do we want the default cache to be optional or actually require it in
>> the declarative configuration ?
>
> In WildFly, default-cache has been optional since WF8.  The
> cache-container used for hibernate 2LC, for example, does not have any
> concept of a default-cache.  So, for us anyway, it makes sense for
> default-cache to be optional.  However, we have the luxury of falling
> back to Infinispan's default getCache() logic in the event that no
> default-cache was specified.
>
>> ** A: no enforcement. In this case requesting the default cache should
>> print a warning about falling back to a "default" empty configuration.
>>
>> ** B: we don't require the user to specify a default cache in the
>> configuration, but invoking getCache() will throw an exception.
>>
>> ** C: enforce it, although this will break all those XML files who
>> haven't specified it.
>>
>> My preference is to use the namespace version and go for the A approach
>> for < 9.0 and the B approach otherwise.
>
> I think that makes sense.
>
>> 2. currently, requesting a named cache for which a configuration hasn't
>> been defined implicitly creates the cache by using the default
>> configuration as a template.
>>
>> ** A: continue as is
>>
>> ** B: continue to implicitly create a cache, but use an empty
>> configuration instead of using the default configuration, as this has
>> been the source of confusion among users. Also print a warning.
>>
>> ** C: do not create caches unless a configuration has been explicitly
>> provided.
>>
>> My preference is to use the namespace version and go for the A approach
>> for < 9.0 and the C approach otherwise.
>
> Agreed.
>
>> Unfortunately the namespace version trick doesn't work for programmatic
>> configurations. Probably we should add a boolean flag on the
>> GlobalConfigurationManager (e.g. implicitCacheCreation) which defaults
>> to false (because that's the "new order") but allows switching to the
>> old behaviour if needed.
>>
>> In any case I'd like to also introduce a JCache-like createCache() API
>
> I think it would be best/cleanest if caches created via this API are
> anonymous (i.e. not managed by the cache manager or made accessible
> via getCache(String)).  That way there is no ambiguity about who is
> meant to manage the lifecycle (user vs container).

Hmm, this differs from the behaviour of JCache's getCache(String) though.

>
>> Tristan
>>
>> On 10/11/16 13:20, Paul Ferraro wrote:
>>> +1000
>>>
>>> This is precisely how we've setup cache manager semantics in WildFly
>>> (since AS7):
>>> https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/spi/src/main/java/org/wildfly/clustering/infinispan/spi/CacheContainer.java
>>> https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/extension/src/main/java/org/jboss/as/clustering/infinispan/DefaultCacheContainer.java
>>>
>>> I'd love to be able to drop this.
>>>
>>> Paul
>>>
>>> On Thu, Nov 10, 2016 at 3:38 AM, Tristan Tarrant <ttarrant at redhat.com> wrote:
>>>> In the discussion for [1] the subject of the default cache and the way
>>>> it affects configuration inheritance came up.
>>>>
>>>> My proposal is:
>>>> - remove the default cache as a special cache altogether
>>>> - CacheManager.getCache()  should return the named cache specified as
>>>> default in the configuration.
>>>> - the programmatic GlobalConfigurationBuilder/GlobalConfiguration should
>>>> have the notion of the default named cache (currently this is handled in
>>>> the parser)
>>>> - Retrieving the cache named "___defaultcache" should actually retrieve
>>>> the above named cache
>>>>
>>>> Opinions ?
>>>>
>>>> Tristan
>>>>
>>>> [1] https://github.com/infinispan/infinispan/pull/4631
>>>> --
>>>> Tristan Tarrant
>>>> Infinispan Lead
>>>> JBoss, a division of Red Hat
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>
>> --
>> Tristan Tarrant
>> Infinispan Lead
>> JBoss, a division of Red Hat
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat

From paul.ferraro at redhat.com  Wed Nov 30 13:08:03 2016
From: paul.ferraro at redhat.com (Paul Ferraro)
Date: Wed, 30 Nov 2016 13:08:03 -0500
Subject: [infinispan-dev] Default cache
In-Reply-To: <a9d82e63-089b-636e-86eb-5322c9350632@redhat.com>
References: <6664a2bc-a7aa-4fbb-4386-76916d2f6813@redhat.com>
	<CAF5qqoMHF=k3h=qYMwrER1V4q0MkH72B=a3kKUdbzvpsfGUw0A@mail.gmail.com>
	<53632d56-e75b-13c8-5d6f-1ad61f5dddc0@redhat.com>
	<CAF5qqoNHmjEB9N6gwYSGh=hvZLE-ECEgJRV4adnyjuRmF_WFeg@mail.gmail.com>
	<a9d82e63-089b-636e-86eb-5322c9350632@redhat.com>
Message-ID: <CAF5qqoPk63A=d-qz4P=JyrUc4CuDrxZ6_J+fW0pTLT_4X5n-NQ@mail.gmail.com>

On Wed, Nov 30, 2016 at 12:41 PM, Tristan Tarrant <ttarrant at redhat.com> wrote:
> On 30/11/16 17:44, Paul Ferraro wrote:
>> On Wed, Nov 30, 2016 at 9:13 AM, Tristan Tarrant <ttarrant at redhat.com> wrote:
>>> Some additional notes:
>>>
>>> - currently the XSD specifies the default-cache attribute on the
>>> cache-container element as required, but the parser doesn't enforce it.
>>> - A default ConfigurationBuilder is created for the default cache if one
>>> has not been specified
>>>
>>> My questions:
>>>
>>> 1. do we want the default cache to be optional or actually require it in
>>> the declarative configuration ?
>>
>> In WildFly, default-cache has been optional since WF8.  The
>> cache-container used for hibernate 2LC, for example, does not have any
>> concept of a default-cache.  So, for us anyway, it makes sense for
>> default-cache to be optional.  However, we have the luxury of falling
>> back to Infinispan's default getCache() logic in the event that no
>> default-cache was specified.
>>
>>> ** A: no enforcement. In this case requesting the default cache should
>>> print a warning about falling back to a "default" empty configuration.
>>>
>>> ** B: we don't require the user to specify a default cache in the
>>> configuration, but invoking getCache() will throw an exception.
>>>
>>> ** C: enforce it, although this will break all those XML files who
>>> haven't specified it.
>>>
>>> My preference is to use the namespace version and go for the A approach
>>> for < 9.0 and the B approach otherwise.
>>
>> I think that makes sense.
>>
>>> 2. currently, requesting a named cache for which a configuration hasn't
>>> been defined implicitly creates the cache by using the default
>>> configuration as a template.
>>>
>>> ** A: continue as is
>>>
>>> ** B: continue to implicitly create a cache, but use an empty
>>> configuration instead of using the default configuration, as this has
>>> been the source of confusion among users. Also print a warning.
>>>
>>> ** C: do not create caches unless a configuration has been explicitly
>>> provided.
>>>
>>> My preference is to use the namespace version and go for the A approach
>>> for < 9.0 and the C approach otherwise.
>>
>> Agreed.
>>
>>> Unfortunately the namespace version trick doesn't work for programmatic
>>> configurations. Probably we should add a boolean flag on the
>>> GlobalConfigurationManager (e.g. implicitCacheCreation) which defaults
>>> to false (because that's the "new order") but allows switching to the
>>> old behaviour if needed.
>>>
>>> In any case I'd like to also introduce a JCache-like createCache() API
>>
>> I think it would be best/cleanest if caches created via this API are
>> anonymous (i.e. not managed by the cache manager or made accessible
>> via getCache(String)).  That way there is no ambiguity about who is
>> meant to manage the lifecycle (user vs container).
>
> Hmm, this differs from the behaviour of JCache's getCache(String) though.

Yes - and this was one of my biggest complaints about this API.  There
ought to be a distinction between "managed" caches vs. "ad hoc"
caches.  This (along with the class loading mess) is one of the
reasons why this spec isn't ready for the EE world.

>>> Tristan
>>>
>>> On 10/11/16 13:20, Paul Ferraro wrote:
>>>> +1000
>>>>
>>>> This is precisely how we've setup cache manager semantics in WildFly
>>>> (since AS7):
>>>> https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/spi/src/main/java/org/wildfly/clustering/infinispan/spi/CacheContainer.java
>>>> https://github.com/wildfly/wildfly/blob/master/clustering/infinispan/extension/src/main/java/org/jboss/as/clustering/infinispan/DefaultCacheContainer.java
>>>>
>>>> I'd love to be able to drop this.
>>>>
>>>> Paul
>>>>
>>>> On Thu, Nov 10, 2016 at 3:38 AM, Tristan Tarrant <ttarrant at redhat.com> wrote:
>>>>> In the discussion for [1] the subject of the default cache and the way
>>>>> it affects configuration inheritance came up.
>>>>>
>>>>> My proposal is:
>>>>> - remove the default cache as a special cache altogether
>>>>> - CacheManager.getCache()  should return the named cache specified as
>>>>> default in the configuration.
>>>>> - the programmatic GlobalConfigurationBuilder/GlobalConfiguration should
>>>>> have the notion of the default named cache (currently this is handled in
>>>>> the parser)
>>>>> - Retrieving the cache named "___defaultcache" should actually retrieve
>>>>> the above named cache
>>>>>
>>>>> Opinions ?
>>>>>
>>>>> Tristan
>>>>>
>>>>> [1] https://github.com/infinispan/infinispan/pull/4631
>>>>> --
>>>>> Tristan Tarrant
>>>>> Infinispan Lead
>>>>> JBoss, a division of Red Hat
>>>>> _______________________________________________
>>>>> infinispan-dev mailing list
>>>>> infinispan-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>>
>>>
>>> --
>>> Tristan Tarrant
>>> Infinispan Lead
>>> JBoss, a division of Red Hat
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>
> --
> Tristan Tarrant
> Infinispan Lead
> JBoss, a division of Red Hat
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev