From mudokonman at gmail.com  Fri Apr  1 12:47:41 2016
From: mudokonman at gmail.com (William Burns)
Date: Fri, 01 Apr 2016 16:47:41 +0000
Subject: [infinispan-dev] Should Tree module be deprecated?
In-Reply-To: <E1F85DCC-124E-48FD-AC63-38D91E2D9BDE@redhat.com>
References: <E1F85DCC-124E-48FD-AC63-38D91E2D9BDE@redhat.com>
Message-ID: <CA+YCuUNjO5WP+6ELJR8Es6MUkD+ApX13KrZjhyarTkaaXTyvng@mail.gmail.com>

I think we should at least deprecate it for 9.0, if not totally remove it
(although I understand we probably can't remove it yet)

TreeCache seems to pop up a lot with people complaining about it.

 - Will

On Tue, Mar 29, 2016 at 3:48 AM Galder Zamarre?o <galder at redhat.com> wrote:

> Re:
> http://stackoverflow.com/questions/29673123/infinispan-treecache-not-getting-distributed-properly?noredirect=1#comment59906993_29673123
>
> Cheers,
> --
> Galder Zamarre?o
> Infinispan, 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/20160401/eaeec1d7/attachment.html 

From slaskawi at redhat.com  Mon Apr  4 13:18:50 2016
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Mon, 4 Apr 2016 19:18:50 +0200
Subject: [infinispan-dev] Infinispan 8.2.1.Final and 8.1.3.Final are out!
Message-ID: <CAA9R9O6ArFDmknLsRHR8=ioz2Uiux8RQSHBfXTJ9upezARhwyg@mail.gmail.com>

Dear all!

I'm happy to announce that Infinispan 8.2.1.Final and 8.1.3.Final have been
released!

Infinispan 8.2.1.Final highlights:

   - Web-based admin console improvements
   - Server startup fixes
   - Decreased GMS join timeout
   - Improved test suite stability
   - Read more on our blog:
   http://blog.infinispan.org/2016/04/infinispan-821final-is-out.html

Infinispan 8.3.1.Final includes:

   - Fixed cluster startup in client server mode
   - Maintenance improvements and bugfixes
   - Read more on our blog:
   http://blog.infinispan.org/2016/04/infinispan-813final-is-out.html

All bits can be downloaded from http://infinispan.org/download/

Happy hacking!
The Infinispan team
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160404/efd8e0cd/attachment.html 

From slaskawi at redhat.com  Mon Apr  4 13:24:33 2016
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Mon, 4 Apr 2016 19:24:33 +0200
Subject: [infinispan-dev] Infinispan 8.2.1.Final and 8.1.3.Final are out!
In-Reply-To: <CAA9R9O6ArFDmknLsRHR8=ioz2Uiux8RQSHBfXTJ9upezARhwyg@mail.gmail.com>
References: <CAA9R9O6ArFDmknLsRHR8=ioz2Uiux8RQSHBfXTJ9upezARhwyg@mail.gmail.com>
Message-ID: <CAA9R9O4gcrULYaU+cpqPpusbKukqA-VVM4xzpsyLFsjU6KmK-w@mail.gmail.com>

I'm sorry for the mistake, of course it's 8.1.3.Final (not 8.3.1.Final).

Cheers
Sebastian

On Mon, Apr 4, 2016 at 7:18 PM, Sebastian Laskawiec <slaskawi at redhat.com>
wrote:

> Dear all!
>
> I'm happy to announce that Infinispan 8.2.1.Final and 8.1.3.Final have
> been released!
>
> Infinispan 8.2.1.Final highlights:
>
>    - Web-based admin console improvements
>    - Server startup fixes
>    - Decreased GMS join timeout
>    - Improved test suite stability
>    - Read more on our blog:
>    http://blog.infinispan.org/2016/04/infinispan-821final-is-out.html
>
> Infinispan 8.3.1.Final includes:
>
>    - Fixed cluster startup in client server mode
>    - Maintenance improvements and bugfixes
>    - Read more on our blog:
>    http://blog.infinispan.org/2016/04/infinispan-813final-is-out.html
>
> All bits can be downloaded from http://infinispan.org/download/
>
> Happy hacking!
> The Infinispan team
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160404/863e7e20/attachment.html 

From galder at redhat.com  Wed Apr  6 05:26:59 2016
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Wed, 6 Apr 2016 11:26:59 +0200
Subject: [infinispan-dev] Passing JCache remote manager propietary
	configuration options (ISPN-6438)
Message-ID: <12D20E07-3057-42D4-815B-FE0454B59352@redhat.com>

Hi all,

I've been looking at [1] and the way I see it, there are two ways to solve this:

1. A key benefit of JCache/JCacheManager is that you can construct JCacheManager instances using standard APIs, e.g. calling Cachie.getCachingProvider().getCacheManager(...). One way to solve this issue would be if we exposed a propietary way to create an Infinispan remote JCacheManager, e.g.

new org.infinispan.jcache.remote.JCacheManager(RemoteCacheManager) or
new org.infinispan.jcache.remote.JCacheManager(ConfigurationBuilder)
...etc, or similar solutions

The problem with this approach is that we force users to create JCacheManager instances using implementation detail APIs.

2. The only way you can pass in implementation specific configuration options to JCacheManager instances using standard APIs is via a Properties file. So, the other solution is to have the missing client configuration options available as being able to configure them via Properties. The main limitation here is that property values must be String values. According to Tristan, this could limit some security configuration for options that can be converted into String values. Looking at org.infinispan.client.hotrod.configuration.SslConfigurationBuilder, the only configuration option that might have such issue is passing in a javax.net.ssl.SSLContext instance, but I don't see the sslContext() method used anywhere...? The rest of SSL options take either a String or char[] so those would not be problematic.

Thoughts?

[1] https://issues.jboss.org/browse/ISPN-6438
--
Galder Zamarre?o
Infinispan, Red Hat



From slaskawi at redhat.com  Wed Apr  6 05:44:29 2016
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Wed, 6 Apr 2016 11:44:29 +0200
Subject: [infinispan-dev] Passing JCache remote manager propietary
 configuration options (ISPN-6438)
In-Reply-To: <12D20E07-3057-42D4-815B-FE0454B59352@redhat.com>
References: <12D20E07-3057-42D4-815B-FE0454B59352@redhat.com>
Message-ID: <CAA9R9O4-kRCWoROLPn3iCf79fiZbvPf=cEW+PmeXb0+rJdom1g@mail.gmail.com>

Option #1 seems reasonable to me (as you mentioned #2 has a lot of
limitations). We could use some kind of adapter for this
(JCacheManagerAdapter.fromRemoteCacheManager(rcm)).
This way we would decouple nice and clean way of creating JCacheManager
from the dirty one.

After this one is implemented - we could propose an extension to JCache JSR
to fabricate JCacheManagers from proprietary managers. I think all vendors
should be open for this...


On Wed, Apr 6, 2016 at 11:26 AM, Galder Zamarre?o <galder at redhat.com> wrote:

> Hi all,
>
> I've been looking at [1] and the way I see it, there are two ways to solve
> this:
>
> 1. A key benefit of JCache/JCacheManager is that you can construct
> JCacheManager instances using standard APIs, e.g. calling
> Cachie.getCachingProvider().getCacheManager(...). One way to solve this
> issue would be if we exposed a propietary way to create an Infinispan
> remote JCacheManager, e.g.
>
> new org.infinispan.jcache.remote.JCacheManager(RemoteCacheManager) or
> new org.infinispan.jcache.remote.JCacheManager(ConfigurationBuilder)
> ...etc, or similar solutions
>
> The problem with this approach is that we force users to create
> JCacheManager instances using implementation detail APIs.
>
> 2. The only way you can pass in implementation specific configuration
> options to JCacheManager instances using standard APIs is via a Properties
> file. So, the other solution is to have the missing client configuration
> options available as being able to configure them via Properties. The main
> limitation here is that property values must be String values. According to
> Tristan, this could limit some security configuration for options that can
> be converted into String values. Looking at
> org.infinispan.client.hotrod.configuration.SslConfigurationBuilder, the
> only configuration option that might have such issue is passing in a
> javax.net.ssl.SSLContext instance, but I don't see the sslContext() method
> used anywhere...? The rest of SSL options take either a String or char[] so
> those would not be problematic.
>
> Thoughts?
>
> [1] https://issues.jboss.org/browse/ISPN-6438
> --
> Galder Zamarre?o
> Infinispan, 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/20160406/357e9afc/attachment-0001.html 

From gustavo at infinispan.org  Wed Apr  6 06:29:54 2016
From: gustavo at infinispan.org (Gustavo Fernandes)
Date: Wed, 6 Apr 2016 11:29:54 +0100
Subject: [infinispan-dev] Passing JCache remote manager propietary
 configuration options (ISPN-6438)
In-Reply-To: <12D20E07-3057-42D4-815B-FE0454B59352@redhat.com>
References: <12D20E07-3057-42D4-815B-FE0454B59352@redhat.com>
Message-ID: <CAH8Ud1F8TcFbA9-ipTmtOuEqmo2JZ-ekyFggcMeXrx-DruZTZw@mail.gmail.com>

On Wed, Apr 6, 2016 at 10:26 AM, Galder Zamarre?o <galder at redhat.com> wrote:

> Hi all,
>
> I've been looking at [1] and the way I see it, there are two ways to solve
> this:
>

> 1. A key benefit of JCache/JCacheManager is that you can construct
> JCacheManager instances using standard APIs, e.g. calling
> Cachie.getCachingProvider().getCacheManager(...). One way to solve this
> issue would be if we exposed a propietary way to create an Infinispan
> remote JCacheManager, e.g.
>
> new org.infinispan.jcache.remote.JCacheManager(RemoteCacheManager) or
> new org.infinispan.jcache.remote.JCacheManager(ConfigurationBuilder)
> ...etc, or similar solutions
>
> The problem with this approach is that we force users to create
> JCacheManager instances using implementation detail APIs.
>
> 2. The only way you can pass in implementation specific configuration
> options to JCacheManager instances using standard APIs is via a Properties
> file. So, the other solution is to have the missing client configuration
> options available as being able to configure them via Properties. The main
> limitation here is that property values must be String values. According to
> Tristan, this could limit some security configuration for options that can
> be converted into String values. Looking at
> org.infinispan.client.hotrod.configuration.SslConfigurationBuilder, the
> only configuration option that might have such issue is passing in a
> javax.net.ssl.SSLContext instance, but I don't see the sslContext() method
> used anywhere...? The rest of SSL options take either a String or char[] so
> those would not be problematic.
>
> Thoughts?
>


Regardless of JCache, I think a HotRod client should be configurable via
properties only (this is needed for [2]) as described in [1], maybe we
could introduce factories for non-String based configs?

[2] https://issues.jboss.org/browse/ISPRK-16


Gustavo



>
> [1] https://issues.jboss.org/browse/ISPN-6438
> --
> Galder Zamarre?o
> Infinispan, 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/20160406/edd384c8/attachment.html 

From galder at redhat.com  Wed Apr  6 09:59:00 2016
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Wed, 6 Apr 2016 15:59:00 +0200
Subject: [infinispan-dev] Passing JCache remote manager propietary
	configuration options (ISPN-6438)
In-Reply-To: <CAA9R9O4-kRCWoROLPn3iCf79fiZbvPf=cEW+PmeXb0+rJdom1g@mail.gmail.com>
References: <12D20E07-3057-42D4-815B-FE0454B59352@redhat.com>
	<CAA9R9O4-kRCWoROLPn3iCf79fiZbvPf=cEW+PmeXb0+rJdom1g@mail.gmail.com>
Message-ID: <8593ADF2-FB66-4A22-A438-90CFD8FEC8D7@redhat.com>


--
Galder Zamarre?o
Infinispan, Red Hat

> On 6 Apr 2016, at 11:44, Sebastian Laskawiec <slaskawi at redhat.com> wrote:
> 
> Option #1 seems reasonable to me (as you mentioned #2 has a lot of limitations). We could use some kind of adapter for this (JCacheManagerAdapter.fromRemoteCacheManager(rcm)). This way we would decouple nice and clean way of creating JCacheManager from the dirty one.

^ You can achieve just that with a static method in JCacheManager, no need for an adapter :|

> 
> After this one is implemented - we could propose an extension to JCache JSR to fabricate JCacheManagers from proprietary managers. I think all vendors should be open for this...

^ Good luck with that, the JSR is now closed and not much seems to be going on.

> 
> 
> On Wed, Apr 6, 2016 at 11:26 AM, Galder Zamarre?o <galder at redhat.com> wrote:
> Hi all,
> 
> I've been looking at [1] and the way I see it, there are two ways to solve this:
> 
> 1. A key benefit of JCache/JCacheManager is that you can construct JCacheManager instances using standard APIs, e.g. calling Cachie.getCachingProvider().getCacheManager(...). One way to solve this issue would be if we exposed a propietary way to create an Infinispan remote JCacheManager, e.g.
> 
> new org.infinispan.jcache.remote.JCacheManager(RemoteCacheManager) or
> new org.infinispan.jcache.remote.JCacheManager(ConfigurationBuilder)
> ...etc, or similar solutions
> 
> The problem with this approach is that we force users to create JCacheManager instances using implementation detail APIs.
> 
> 2. The only way you can pass in implementation specific configuration options to JCacheManager instances using standard APIs is via a Properties file. So, the other solution is to have the missing client configuration options available as being able to configure them via Properties. The main limitation here is that property values must be String values. According to Tristan, this could limit some security configuration for options that can be converted into String values. Looking at org.infinispan.client.hotrod.configuration.SslConfigurationBuilder, the only configuration option that might have such issue is passing in a javax.net.ssl.SSLContext instance, but I don't see the sslContext() method used anywhere...? The rest of SSL options take either a String or char[] so those would not be problematic.
> 
> Thoughts?
> 
> [1] https://issues.jboss.org/browse/ISPN-6438
> --
> Galder Zamarre?o
> Infinispan, 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



From galder at redhat.com  Wed Apr  6 10:01:32 2016
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Wed, 6 Apr 2016 16:01:32 +0200
Subject: [infinispan-dev] Passing JCache remote manager propietary
	configuration options (ISPN-6438)
In-Reply-To: <CAH8Ud1F8TcFbA9-ipTmtOuEqmo2JZ-ekyFggcMeXrx-DruZTZw@mail.gmail.com>
References: <12D20E07-3057-42D4-815B-FE0454B59352@redhat.com>
	<CAH8Ud1F8TcFbA9-ipTmtOuEqmo2JZ-ekyFggcMeXrx-DruZTZw@mail.gmail.com>
Message-ID: <4E937F8F-B3C9-4C2F-B806-27FC365BAAA4@redhat.com>


--
Galder Zamarre?o
Infinispan, Red Hat

> On 6 Apr 2016, at 12:29, Gustavo Fernandes <gustavo at infinispan.org> wrote:
> 
> 
> 
> On Wed, Apr 6, 2016 at 10:26 AM, Galder Zamarre?o <galder at redhat.com> wrote:
> Hi all,
> 
> I've been looking at [1] and the way I see it, there are two ways to solve this: 
> 
> 1. A key benefit of JCache/JCacheManager is that you can construct JCacheManager instances using standard APIs, e.g. calling Cachie.getCachingProvider().getCacheManager(...). One way to solve this issue would be if we exposed a propietary way to create an Infinispan remote JCacheManager, e.g.
> 
> new org.infinispan.jcache.remote.JCacheManager(RemoteCacheManager) or
> new org.infinispan.jcache.remote.JCacheManager(ConfigurationBuilder)
> ...etc, or similar solutions
> 
> The problem with this approach is that we force users to create JCacheManager instances using implementation detail APIs.
> 
> 2. The only way you can pass in implementation specific configuration options to JCacheManager instances using standard APIs is via a Properties file. So, the other solution is to have the missing client configuration options available as being able to configure them via Properties. The main limitation here is that property values must be String values. According to Tristan, this could limit some security configuration for options that can be converted into String values. Looking at org.infinispan.client.hotrod.configuration.SslConfigurationBuilder, the only configuration option that might have such issue is passing in a javax.net.ssl.SSLContext instance, but I don't see the sslContext() method used anywhere...? The rest of SSL options take either a String or char[] so those would not be problematic.
> 
> Thoughts?
> 
> 
> Regardless of JCache, I think a HotRod client should be configurable via properties only (this is needed for [2]) as described in [1], maybe we could introduce factories for non-String based configs?

Interesting idea about using factories for non-String configs but not sure that will work? I mean, you'd provide the FQN of the factory class, which would be instantiated with reflection an an empty constructor. What about if that factory relied on some kind of initialization? IOW, if the thing you're building comes from something else?

I don't know the SSLContext use case enough to know if your suggestion would work. Maybe @Tristan can chime in?

Cheers,

> 
> [2] https://issues.jboss.org/browse/ISPRK-16
> 
> 
> Gustavo
> 
>  
> 
> [1] https://issues.jboss.org/browse/ISPN-6438
> --
> Galder Zamarre?o
> Infinispan, 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



From sanne at infinispan.org  Wed Apr  6 10:27:54 2016
From: sanne at infinispan.org (Sanne Grinovero)
Date: Wed, 6 Apr 2016 15:27:54 +0100
Subject: [infinispan-dev] Passing JCache remote manager propietary
 configuration options (ISPN-6438)
In-Reply-To: <4E937F8F-B3C9-4C2F-B806-27FC365BAAA4@redhat.com>
References: <12D20E07-3057-42D4-815B-FE0454B59352@redhat.com>
	<CAH8Ud1F8TcFbA9-ipTmtOuEqmo2JZ-ekyFggcMeXrx-DruZTZw@mail.gmail.com>
	<4E937F8F-B3C9-4C2F-B806-27FC365BAAA4@redhat.com>
Message-ID: <CAFm4XO2DnE6Auv6HCi1MT0AmotK4SzL_u7GyfrPSREnKm5XyiA@mail.gmail.com>

On 6 April 2016 at 15:01, Galder Zamarre?o <galder at redhat.com> wrote:
>
> --
> Galder Zamarre?o
> Infinispan, Red Hat
>
>> On 6 Apr 2016, at 12:29, Gustavo Fernandes <gustavo at infinispan.org> wrote:
>>
>>
>>
>> On Wed, Apr 6, 2016 at 10:26 AM, Galder Zamarre?o <galder at redhat.com> wrote:
>> Hi all,
>>
>> I've been looking at [1] and the way I see it, there are two ways to solve this:
>>
>> 1. A key benefit of JCache/JCacheManager is that you can construct JCacheManager instances using standard APIs, e.g. calling Cachie.getCachingProvider().getCacheManager(...). One way to solve this issue would be if we exposed a propietary way to create an Infinispan remote JCacheManager, e.g.
>>
>> new org.infinispan.jcache.remote.JCacheManager(RemoteCacheManager) or
>> new org.infinispan.jcache.remote.JCacheManager(ConfigurationBuilder)
>> ...etc, or similar solutions
>>
>> The problem with this approach is that we force users to create JCacheManager instances using implementation detail APIs.
>>
>> 2. The only way you can pass in implementation specific configuration options to JCacheManager instances using standard APIs is via a Properties file. So, the other solution is to have the missing client configuration options available as being able to configure them via Properties. The main limitation here is that property values must be String values. According to Tristan, this could limit some security configuration for options that can be converted into String values. Looking at org.infinispan.client.hotrod.configuration.SslConfigurationBuilder, the only configuration option that might have such issue is passing in a javax.net.ssl.SSLContext instance, but I don't see the sslContext() method used anywhere...? The rest of SSL options take either a String or char[] so those would not be problematic.
>>
>> Thoughts?
>>
>>
>> Regardless of JCache, I think a HotRod client should be configurable via properties only (this is needed for [2]) as described in [1], maybe we could introduce factories for non-String based configs?
>
> Interesting idea about using factories for non-String configs but not sure that will work? I mean, you'd provide the FQN of the factory class, which would be instantiated with reflection an an empty constructor. What about if that factory relied on some kind of initialization? IOW, if the thing you're building comes from something else?

+1 to stick to use only properties for Hot Rod so I can embed them all
in configuration files for Hibernate OGM ;)

In Hibernate it's common to allow passing such a factory within the
configuration Map.
If the value of the properties map is a String, then it's interpreted
as a FQN and started via reflection; if it's not a String it verifies
that it is an _instance_ of the required contract, and takes the
instance as is. So integrating frameworks can inject more complex
stuff by simple reference.

That's for example how WildFly injects stuff into Hibernate ORM to use
in most cases; in some cases it still uses the "old style" approach of
defining a jndi lookup convention, but most such JNDI names area also
injected, if it's not injecting the "lookup strategy" by FQN: having
both gives you lots of flexibility.

Thanks,
Sanne

>
> I don't know the SSLContext use case enough to know if your suggestion would work. Maybe @Tristan can chime in?
>
> Cheers,
>
>>
>> [2] https://issues.jboss.org/browse/ISPRK-16
>>
>>
>> Gustavo
>>
>>
>>
>> [1] https://issues.jboss.org/browse/ISPN-6438
>> --
>> Galder Zamarre?o
>> Infinispan, 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 dan.berindei at gmail.com  Wed Apr  6 10:57:13 2016
From: dan.berindei at gmail.com (Dan Berindei)
Date: Wed, 6 Apr 2016 17:57:13 +0300
Subject: [infinispan-dev] Passing JCache remote manager propietary
 configuration options (ISPN-6438)
In-Reply-To: <CAFm4XO2DnE6Auv6HCi1MT0AmotK4SzL_u7GyfrPSREnKm5XyiA@mail.gmail.com>
References: <12D20E07-3057-42D4-815B-FE0454B59352@redhat.com>
	<CAH8Ud1F8TcFbA9-ipTmtOuEqmo2JZ-ekyFggcMeXrx-DruZTZw@mail.gmail.com>
	<4E937F8F-B3C9-4C2F-B806-27FC365BAAA4@redhat.com>
	<CAFm4XO2DnE6Auv6HCi1MT0AmotK4SzL_u7GyfrPSREnKm5XyiA@mail.gmail.com>
Message-ID: <CA+nfvwQY8NpVCLCUTp2ce4aVQ+_ReRu-OqZUb7AryCnokWXQ0g@mail.gmail.com>

On Wed, Apr 6, 2016 at 5:27 PM, Sanne Grinovero <sanne at infinispan.org> wrote:
> On 6 April 2016 at 15:01, Galder Zamarre?o <galder at redhat.com> wrote:
>>
>> --
>> Galder Zamarre?o
>> Infinispan, Red Hat
>>
>>> On 6 Apr 2016, at 12:29, Gustavo Fernandes <gustavo at infinispan.org> wrote:
>>>
>>>
>>>
>>> On Wed, Apr 6, 2016 at 10:26 AM, Galder Zamarre?o <galder at redhat.com> wrote:
>>> Hi all,
>>>
>>> I've been looking at [1] and the way I see it, there are two ways to solve this:
>>>
>>> 1. A key benefit of JCache/JCacheManager is that you can construct JCacheManager instances using standard APIs, e.g. calling Cachie.getCachingProvider().getCacheManager(...). One way to solve this issue would be if we exposed a propietary way to create an Infinispan remote JCacheManager, e.g.
>>>
>>> new org.infinispan.jcache.remote.JCacheManager(RemoteCacheManager) or
>>> new org.infinispan.jcache.remote.JCacheManager(ConfigurationBuilder)
>>> ...etc, or similar solutions
>>>
>>> The problem with this approach is that we force users to create JCacheManager instances using implementation detail APIs.
>>>
>>> 2. The only way you can pass in implementation specific configuration options to JCacheManager instances using standard APIs is via a Properties file. So, the other solution is to have the missing client configuration options available as being able to configure them via Properties. The main limitation here is that property values must be String values. According to Tristan, this could limit some security configuration for options that can be converted into String values. Looking at org.infinispan.client.hotrod.configuration.SslConfigurationBuilder, the only configuration option that might have such issue is passing in a javax.net.ssl.SSLContext instance, but I don't see the sslContext() method used anywhere...? The rest of SSL options take either a String or char[] so those would not be problematic.
>>>
>>> Thoughts?
>>>
>>>
>>> Regardless of JCache, I think a HotRod client should be configurable via properties only (this is needed for [2]) as described in [1], maybe we could introduce factories for non-String based configs?
>>
>> Interesting idea about using factories for non-String configs but not sure that will work? I mean, you'd provide the FQN of the factory class, which would be instantiated with reflection an an empty constructor. What about if that factory relied on some kind of initialization? IOW, if the thing you're building comes from something else?
>
> +1 to stick to use only properties for Hot Rod so I can embed them all
> in configuration files for Hibernate OGM ;)
>
> In Hibernate it's common to allow passing such a factory within the
> configuration Map.
> If the value of the properties map is a String, then it's interpreted
> as a FQN and started via reflection; if it's not a String it verifies
> that it is an _instance_ of the required contract, and takes the
> instance as is. So integrating frameworks can inject more complex
> stuff by simple reference.

Our standard configuration API also allows custom implementations that
can be provided either as an instance or as a class name. Usually it's
the actual implementation, not a factory.

The limitation with JSR-107 is that we want it to work with
Caching.getCachingProvider().getCacheManager(...), which can take in
only a Properties instance and pass that to the cache manager.
So far, we assumed all the Properties values must be Strings. However,
it looks like Properties extends Hashtable<Object,Object>, so it
should be possible to stick any object in there. The only gotcha is
that the caller must use Properties.put(k, v) instead of
Properties.setProperty(k, v).

>
> That's for example how WildFly injects stuff into Hibernate ORM to use
> in most cases; in some cases it still uses the "old style" approach of
> defining a jndi lookup convention, but most such JNDI names area also
> injected, if it's not injecting the "lookup strategy" by FQN: having
> both gives you lots of flexibility.

I also suggested JNDI, but I was quickly reminded that JNDI isn't
always available, and we don't want to make it a required dependency.

We could also have a singleton map for "injectables", and replace JNDI
references with keys in our injectables map. Still, I'm always wary
about static stuff, so I like the "hack" of storing non-String values
in a Properties instance better.

Cheers
Dan

>
> Thanks,
> Sanne
>
>>
>> I don't know the SSLContext use case enough to know if your suggestion would work. Maybe @Tristan can chime in?
>>
>> Cheers,
>>
>>>
>>> [2] https://issues.jboss.org/browse/ISPRK-16
>>>
>>>
>>> Gustavo
>>>
>>>
>>>
>>> [1] https://issues.jboss.org/browse/ISPN-6438
>>> --
>>> Galder Zamarre?o
>>> Infinispan, 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
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


From ttarrant at redhat.com  Wed Apr  6 11:02:15 2016
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Wed, 6 Apr 2016 17:02:15 +0200
Subject: [infinispan-dev] Passing JCache remote manager propietary
 configuration options (ISPN-6438)
In-Reply-To: <CA+nfvwQY8NpVCLCUTp2ce4aVQ+_ReRu-OqZUb7AryCnokWXQ0g@mail.gmail.com>
References: <12D20E07-3057-42D4-815B-FE0454B59352@redhat.com>
	<CAH8Ud1F8TcFbA9-ipTmtOuEqmo2JZ-ekyFggcMeXrx-DruZTZw@mail.gmail.com>
	<4E937F8F-B3C9-4C2F-B806-27FC365BAAA4@redhat.com>
	<CAFm4XO2DnE6Auv6HCi1MT0AmotK4SzL_u7GyfrPSREnKm5XyiA@mail.gmail.com>
	<CA+nfvwQY8NpVCLCUTp2ce4aVQ+_ReRu-OqZUb7AryCnokWXQ0g@mail.gmail.com>
Message-ID: <570524F7.6040009@redhat.com>



On 06/04/2016 16:57, Dan Berindei wrote:
> On Wed, Apr 6, 2016 at 5:27 PM, Sanne Grinovero <sanne at infinispan.org> wrote:
>> On 6 April 2016 at 15:01, Galder Zamarre?o <galder at redhat.com> wrote:
>>>
>>> --
>>> Galder Zamarre?o
>>> Infinispan, Red Hat
>>>
>>>> On 6 Apr 2016, at 12:29, Gustavo Fernandes <gustavo at infinispan.org> wrote:
>>>>
>>>>
>>>>
>>>> On Wed, Apr 6, 2016 at 10:26 AM, Galder Zamarre?o <galder at redhat.com> wrote:
>>>> Hi all,
>>>>
>>>> I've been looking at [1] and the way I see it, there are two ways to solve this:
>>>>
>>>> 1. A key benefit of JCache/JCacheManager is that you can construct JCacheManager instances using standard APIs, e.g. calling Cachie.getCachingProvider().getCacheManager(...). One way to solve this issue would be if we exposed a propietary way to create an Infinispan remote JCacheManager, e.g.
>>>>
>>>> new org.infinispan.jcache.remote.JCacheManager(RemoteCacheManager) or
>>>> new org.infinispan.jcache.remote.JCacheManager(ConfigurationBuilder)
>>>> ...etc, or similar solutions
>>>>
>>>> The problem with this approach is that we force users to create JCacheManager instances using implementation detail APIs.
>>>>
>>>> 2. The only way you can pass in implementation specific configuration options to JCacheManager instances using standard APIs is via a Properties file. So, the other solution is to have the missing client configuration options available as being able to configure them via Properties. The main limitation here is that property values must be String values. According to Tristan, this could limit some security configuration for options that can be converted into String values. Looking at org.infinispan.client.hotrod.configuration.SslConfigurationBuilder, the only configuration option that might have such issue is passing in a javax.net.ssl.SSLContext instance, but I don't see the sslContext() method used anywhere...? The rest of SSL options take either a String or char[] so those would not be problematic.
>>>>
>>>> Thoughts?
>>>>
>>>>
>>>> Regardless of JCache, I think a HotRod client should be configurable via properties only (this is needed for [2]) as described in [1], maybe we could introduce factories for non-String based configs?
>>>
>>> Interesting idea about using factories for non-String configs but not sure that will work? I mean, you'd provide the FQN of the factory class, which would be instantiated with reflection an an empty constructor. What about if that factory relied on some kind of initialization? IOW, if the thing you're building comes from something else?
>>
>> +1 to stick to use only properties for Hot Rod so I can embed them all
>> in configuration files for Hibernate OGM ;)
>>
>> In Hibernate it's common to allow passing such a factory within the
>> configuration Map.
>> If the value of the properties map is a String, then it's interpreted.
>> as a FQN and started via reflection; if it's not a String it verifies
>> that it is an _instance_ of the required contract, and takes the
>> instance as is. So integrating frameworks can inject more complex
>> stuff by simple reference.
>
> Our standard configuration API also allows custom implementations that
> can be provided either as an instance or as a class name. Usually it's
> the actual implementation, not a factory.
>
> The limitation with JSR-107 is that we want it to work with
> Caching.getCachingProvider().getCacheManager(...), which can take in
> only a Properties instance and pass that to the cache manager.
> So far, we assumed all the Properties values must be Strings. However,
> it looks like Properties extends Hashtable<Object,Object>, so it
> should be possible to stick any object in there. The only gotcha is
> that the caller must use Properties.put(k, v) instead of
> Properties.setProperty(k, v).

This was the approach I was going to suggest.

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

From sanne at infinispan.org  Wed Apr  6 11:08:26 2016
From: sanne at infinispan.org (Sanne Grinovero)
Date: Wed, 6 Apr 2016 16:08:26 +0100
Subject: [infinispan-dev] Passing JCache remote manager propietary
 configuration options (ISPN-6438)
In-Reply-To: <CA+nfvwQY8NpVCLCUTp2ce4aVQ+_ReRu-OqZUb7AryCnokWXQ0g@mail.gmail.com>
References: <12D20E07-3057-42D4-815B-FE0454B59352@redhat.com>
	<CAH8Ud1F8TcFbA9-ipTmtOuEqmo2JZ-ekyFggcMeXrx-DruZTZw@mail.gmail.com>
	<4E937F8F-B3C9-4C2F-B806-27FC365BAAA4@redhat.com>
	<CAFm4XO2DnE6Auv6HCi1MT0AmotK4SzL_u7GyfrPSREnKm5XyiA@mail.gmail.com>
	<CA+nfvwQY8NpVCLCUTp2ce4aVQ+_ReRu-OqZUb7AryCnokWXQ0g@mail.gmail.com>
Message-ID: <CAFm4XO2kR16LQo2iy34uy0YAyiyXPi6CGQhjOMPK1US5D=HpQg@mail.gmail.com>

On 6 April 2016 at 15:57, Dan Berindei <dan.berindei at gmail.com> wrote:
> On Wed, Apr 6, 2016 at 5:27 PM, Sanne Grinovero <sanne at infinispan.org> wrote:
>> On 6 April 2016 at 15:01, Galder Zamarre?o <galder at redhat.com> wrote:
>>>
>>> --
>>> Galder Zamarre?o
>>> Infinispan, Red Hat
>>>
>>>> On 6 Apr 2016, at 12:29, Gustavo Fernandes <gustavo at infinispan.org> wrote:
>>>>
>>>>
>>>>
>>>> On Wed, Apr 6, 2016 at 10:26 AM, Galder Zamarre?o <galder at redhat.com> wrote:
>>>> Hi all,
>>>>
>>>> I've been looking at [1] and the way I see it, there are two ways to solve this:
>>>>
>>>> 1. A key benefit of JCache/JCacheManager is that you can construct JCacheManager instances using standard APIs, e.g. calling Cachie.getCachingProvider().getCacheManager(...). One way to solve this issue would be if we exposed a propietary way to create an Infinispan remote JCacheManager, e.g.
>>>>
>>>> new org.infinispan.jcache.remote.JCacheManager(RemoteCacheManager) or
>>>> new org.infinispan.jcache.remote.JCacheManager(ConfigurationBuilder)
>>>> ...etc, or similar solutions
>>>>
>>>> The problem with this approach is that we force users to create JCacheManager instances using implementation detail APIs.
>>>>
>>>> 2. The only way you can pass in implementation specific configuration options to JCacheManager instances using standard APIs is via a Properties file. So, the other solution is to have the missing client configuration options available as being able to configure them via Properties. The main limitation here is that property values must be String values. According to Tristan, this could limit some security configuration for options that can be converted into String values. Looking at org.infinispan.client.hotrod.configuration.SslConfigurationBuilder, the only configuration option that might have such issue is passing in a javax.net.ssl.SSLContext instance, but I don't see the sslContext() method used anywhere...? The rest of SSL options take either a String or char[] so those would not be problematic.
>>>>
>>>> Thoughts?
>>>>
>>>>
>>>> Regardless of JCache, I think a HotRod client should be configurable via properties only (this is needed for [2]) as described in [1], maybe we could introduce factories for non-String based configs?
>>>
>>> Interesting idea about using factories for non-String configs but not sure that will work? I mean, you'd provide the FQN of the factory class, which would be instantiated with reflection an an empty constructor. What about if that factory relied on some kind of initialization? IOW, if the thing you're building comes from something else?
>>
>> +1 to stick to use only properties for Hot Rod so I can embed them all
>> in configuration files for Hibernate OGM ;)
>>
>> In Hibernate it's common to allow passing such a factory within the
>> configuration Map.
>> If the value of the properties map is a String, then it's interpreted
>> as a FQN and started via reflection; if it's not a String it verifies
>> that it is an _instance_ of the required contract, and takes the
>> instance as is. So integrating frameworks can inject more complex
>> stuff by simple reference.
>
> Our standard configuration API also allows custom implementations that
> can be provided either as an instance or as a class name. Usually it's
> the actual implementation, not a factory.
>
> The limitation with JSR-107 is that we want it to work with
> Caching.getCachingProvider().getCacheManager(...), which can take in
> only a Properties instance and pass that to the cache manager.
> So far, we assumed all the Properties values must be Strings. However,
> it looks like Properties extends Hashtable<Object,Object>, so it
> should be possible to stick any object in there. The only gotcha is
> that the caller must use Properties.put(k, v) instead of
> Properties.setProperty(k, v).

Yes that's exactly what Hibernate does. The API takes a "Properties"
but people can shovel in other things than just Strings.

>
>>
>> That's for example how WildFly injects stuff into Hibernate ORM to use
>> in most cases; in some cases it still uses the "old style" approach of
>> defining a jndi lookup convention, but most such JNDI names area also
>> injected, if it's not injecting the "lookup strategy" by FQN: having
>> both gives you lots of flexibility.
>
> I also suggested JNDI, but I was quickly reminded that JNDI isn't
> always available, and we don't want to make it a required dependency.

I didn't mean to suggest JNDI explicitly, just that if you accept
either FQN names in string form or the instance directly, then people
can do anything and including pass in strategies to look up via JNDI
if they prefer to.

>
> We could also have a singleton map for "injectables", and replace JNDI
> references with keys in our injectables map. Still, I'm always wary
> about static stuff, so I like the "hack" of storing non-String values
> in a Properties instance better.

+1

Thanks,
Sanne

>
> Cheers
> Dan
>
>>
>> Thanks,
>> Sanne
>>
>>>
>>> I don't know the SSLContext use case enough to know if your suggestion would work. Maybe @Tristan can chime in?
>>>
>>> Cheers,
>>>
>>>>
>>>> [2] https://issues.jboss.org/browse/ISPRK-16
>>>>
>>>>
>>>> Gustavo
>>>>
>>>>
>>>>
>>>> [1] https://issues.jboss.org/browse/ISPN-6438
>>>> --
>>>> Galder Zamarre?o
>>>> Infinispan, 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
>>
>> _______________________________________________
>> 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 galder at redhat.com  Thu Apr  7 06:17:18 2016
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Thu, 7 Apr 2016 12:17:18 +0200
Subject: [infinispan-dev] Passing JCache remote manager propietary
	configuration options (ISPN-6438)
In-Reply-To: <CA+nfvwQY8NpVCLCUTp2ce4aVQ+_ReRu-OqZUb7AryCnokWXQ0g@mail.gmail.com>
References: <12D20E07-3057-42D4-815B-FE0454B59352@redhat.com>
	<CAH8Ud1F8TcFbA9-ipTmtOuEqmo2JZ-ekyFggcMeXrx-DruZTZw@mail.gmail.com>
	<4E937F8F-B3C9-4C2F-B806-27FC365BAAA4@redhat.com>
	<CAFm4XO2DnE6Auv6HCi1MT0AmotK4SzL_u7GyfrPSREnKm5XyiA@mail.gmail.com>
	<CA+nfvwQY8NpVCLCUTp2ce4aVQ+_ReRu-OqZUb7AryCnokWXQ0g@mail.gmail.com>
Message-ID: <DD61D4AA-E3DA-460A-AE9F-67F4C4AE8F46@redhat.com>


--
Galder Zamarre?o
Infinispan, Red Hat

> On 6 Apr 2016, at 16:57, Dan Berindei <dan.berindei at gmail.com> wrote:
> 
> On Wed, Apr 6, 2016 at 5:27 PM, Sanne Grinovero <sanne at infinispan.org> wrote:
>> On 6 April 2016 at 15:01, Galder Zamarre?o <galder at redhat.com> wrote:
>>> 
>>> --
>>> Galder Zamarre?o
>>> Infinispan, Red Hat
>>> 
>>>> On 6 Apr 2016, at 12:29, Gustavo Fernandes <gustavo at infinispan.org> wrote:
>>>> 
>>>> 
>>>> 
>>>> On Wed, Apr 6, 2016 at 10:26 AM, Galder Zamarre?o <galder at redhat.com> wrote:
>>>> Hi all,
>>>> 
>>>> I've been looking at [1] and the way I see it, there are two ways to solve this:
>>>> 
>>>> 1. A key benefit of JCache/JCacheManager is that you can construct JCacheManager instances using standard APIs, e.g. calling Cachie.getCachingProvider().getCacheManager(...). One way to solve this issue would be if we exposed a propietary way to create an Infinispan remote JCacheManager, e.g.
>>>> 
>>>> new org.infinispan.jcache.remote.JCacheManager(RemoteCacheManager) or
>>>> new org.infinispan.jcache.remote.JCacheManager(ConfigurationBuilder)
>>>> ...etc, or similar solutions
>>>> 
>>>> The problem with this approach is that we force users to create JCacheManager instances using implementation detail APIs.
>>>> 
>>>> 2. The only way you can pass in implementation specific configuration options to JCacheManager instances using standard APIs is via a Properties file. So, the other solution is to have the missing client configuration options available as being able to configure them via Properties. The main limitation here is that property values must be String values. According to Tristan, this could limit some security configuration for options that can be converted into String values. Looking at org.infinispan.client.hotrod.configuration.SslConfigurationBuilder, the only configuration option that might have such issue is passing in a javax.net.ssl.SSLContext instance, but I don't see the sslContext() method used anywhere...? The rest of SSL options take either a String or char[] so those would not be problematic.
>>>> 
>>>> Thoughts?
>>>> 
>>>> 
>>>> Regardless of JCache, I think a HotRod client should be configurable via properties only (this is needed for [2]) as described in [1], maybe we could introduce factories for non-String based configs?
>>> 
>>> Interesting idea about using factories for non-String configs but not sure that will work? I mean, you'd provide the FQN of the factory class, which would be instantiated with reflection an an empty constructor. What about if that factory relied on some kind of initialization? IOW, if the thing you're building comes from something else?
>> 
>> +1 to stick to use only properties for Hot Rod so I can embed them all
>> in configuration files for Hibernate OGM ;)
>> 
>> In Hibernate it's common to allow passing such a factory within the
>> configuration Map.
>> If the value of the properties map is a String, then it's interpreted
>> as a FQN and started via reflection; if it's not a String it verifies
>> that it is an _instance_ of the required contract, and takes the
>> instance as is. So integrating frameworks can inject more complex
>> stuff by simple reference.
> 
> Our standard configuration API also allows custom implementations that
> can be provided either as an instance or as a class name. Usually it's
> the actual implementation, not a factory.
> 
> The limitation with JSR-107 is that we want it to work with
> Caching.getCachingProvider().getCacheManager(...), which can take in
> only a Properties instance and pass that to the cache manager.
> So far, we assumed all the Properties values must be Strings. However,
> it looks like Properties extends Hashtable<Object,Object>, so it
> should be possible to stick any object in there. The only gotcha is
> that the caller must use Properties.put(k, v) instead of
> Properties.setProperty(k, v).

^ I had not noticed that! Feels a bit dirty but that'll do :)

> 
>> 
>> That's for example how WildFly injects stuff into Hibernate ORM to use
>> in most cases; in some cases it still uses the "old style" approach of
>> defining a jndi lookup convention, but most such JNDI names area also
>> injected, if it's not injecting the "lookup strategy" by FQN: having
>> both gives you lots of flexibility.
> 
> I also suggested JNDI, but I was quickly reminded that JNDI isn't
> always available, and we don't want to make it a required dependency.
> 
> We could also have a singleton map for "injectables", and replace JNDI
> references with keys in our injectables map. Still, I'm always wary
> about static stuff, so I like the "hack" of storing non-String values
> in a Properties instance better.
> 
> Cheers
> Dan
> 
>> 
>> Thanks,
>> Sanne
>> 
>>> 
>>> I don't know the SSLContext use case enough to know if your suggestion would work. Maybe @Tristan can chime in?
>>> 
>>> Cheers,
>>> 
>>>> 
>>>> [2] https://issues.jboss.org/browse/ISPRK-16
>>>> 
>>>> 
>>>> Gustavo
>>>> 
>>>> 
>>>> 
>>>> [1] https://issues.jboss.org/browse/ISPN-6438
>>>> --
>>>> Galder Zamarre?o
>>>> Infinispan, 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
>> 
>> _______________________________________________
>> 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 ttarrant at redhat.com  Thu Apr  7 08:20:38 2016
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Thu, 7 Apr 2016 14:20:38 +0200
Subject: [infinispan-dev] Should Tree module be deprecated?
In-Reply-To: <CA+YCuUNjO5WP+6ELJR8Es6MUkD+ApX13KrZjhyarTkaaXTyvng@mail.gmail.com>
References: <E1F85DCC-124E-48FD-AC63-38D91E2D9BDE@redhat.com>
	<CA+YCuUNjO5WP+6ELJR8Es6MUkD+ApX13KrZjhyarTkaaXTyvng@mail.gmail.com>
Message-ID: <57065096.6040702@redhat.com>

We should really try to understand the reason why people want a 
treecache. If it is just for ease of porting from JBossCache, then we 
should write an article detailing different strategies on migrating to 
the Map before we proceed with the deprecation (although I'm strongly in 
favour of it).

Tristan

On 01/04/2016 18:47, William Burns wrote:
> I think we should at least deprecate it for 9.0, if not totally remove
> it (although I understand we probably can't remove it yet)
>
> TreeCache seems to pop up a lot with people complaining about it.
>
>   - Will
>
> On Tue, Mar 29, 2016 at 3:48 AM Galder Zamarre?o <galder at redhat.com
> <mailto:galder at redhat.com>> wrote:
>
>     Re:
>     http://stackoverflow.com/questions/29673123/infinispan-treecache-not-getting-distributed-properly?noredirect=1#comment59906993_29673123
>
>     Cheers,
>     --
>     Galder Zamarre?o
>     Infinispan, 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
>
>
>
> _______________________________________________
> 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 galder at redhat.com  Thu Apr  7 08:26:56 2016
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Thu, 7 Apr 2016 14:26:56 +0200
Subject: [infinispan-dev] Disabling OSGI on IntelliJ
Message-ID: <FB5A3A00-84A2-46D8-B64B-81C8D89E9D84@redhat.com>

If you need to disable OSGi plugins in IntelliJ, make sure you also disable Osmorc. Somehow this plugin is not found even if you search for 'osgi':
https://youtrack.jetbrains.com/issue/IDEA-154323

Cheers,
--
Galder Zamarre?o
Infinispan, Red Hat



From ttarrant at redhat.com  Thu Apr  7 08:28:47 2016
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Thu, 7 Apr 2016 14:28:47 +0200
Subject: [infinispan-dev] Distributed Counter Discussion
In-Reply-To: <CAFm4XO3rPD60WasjxdzawqQKEd0VTa4Vw5As0urah1RDP9++Pw@mail.gmail.com>
References: <56E70D92.1010206@infinispan.org>
	<E1D724FA-65AD-464F-A3EE-D65057AC4FBB@redhat.com>
	<56FABA94.5010104@infinispan.org>
	<CAFm4XO3rPD60WasjxdzawqQKEd0VTa4Vw5As0urah1RDP9++Pw@mail.gmail.com>
Message-ID: <5706527F.6040608@redhat.com>

I think the main interface definition (as it is) is fine, but it needs 
to be subclassed into two different behaviours:

- "sync": the value returned by the CF is consistent across the cluster
- "eventually consistent": the value returned by the CF might be stale 
(maybe return its latest "localh" value)

Tristan

On 30/03/2016 12:34, Sanne Grinovero wrote:
> Hi Pedro,
> there have been many questions on this thread pointing out the need to
> clarify the definition and which requirements it aims to solve. I
> don't think we can comment on the API proposal without making that
> clear first?
>
> It seems there was some consensus that this doesn't help for the
> APIMan use case; could we clarify the goal and use cases then?
>
> thanks,
> Sanne
>
> On 29 March 2016 at 18:25, Pedro Ruivo <pedro at infinispan.org> wrote:
>> == Status update ==
>>
>> Hi all,
>>
>> The work in progress can be found in [1].
>>
>> The main interface is:
>>
>> CompletableFuture<Long> addAndGet(long)
>>
>> The CompletableFuture will allow to cover a more use cases, for example,
>> if you need to count the number of visits, you can increment without
>> waiting it to complete. On other hand, if you need "unique ids", it is
>> possible to increment and wait for the result.
>>
>> * Let me know any concerns with it.
>>
>> Currently, two types of counters can be returned by the counter manager:
>> "unlimited" and limited (i.e. with thresholds).
>>
>> "Unlimited" is actually limited to Long.MAX_VALUE but will never throw
>> any exception when reached.
>> The limited version throws a CounterException when the min or max
>> threshold is reached.
>> In both cases, it doesn't overflow the counter value.
>>
>> Currently, I'm working in the notification mechanism. So, just ignore
>> that part of the code :)
>>
>> Moving to the next problem, I need an opinion how to create the counter
>> manager.
>>
>> The current implementation is using a private cache. It has the
>> advantage of starting the cache when a cache manager starts, however, it
>> is a bit difficult to configure (e.g. persistence). Also, it does not
>> allow different configuration for the counter (replicated vs
>> distributed, persisted or not).
>>
>> Another alternative, it to construct the counter manager with the cache
>> manager and a cache name. This looks simpler and it allows the user to
>> configure it properly and have different counter manager with different
>> configurations.
>>
>> * Comments are welcome.
>>
>> Cheers,
>> Pedro
>>
>> [1] https://github.com/pruivo/infinispan/tree/t_counters/distributed-counter
>> _______________________________________________
>> 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 sanne at infinispan.org  Thu Apr  7 09:06:16 2016
From: sanne at infinispan.org (Sanne Grinovero)
Date: Thu, 7 Apr 2016 14:06:16 +0100
Subject: [infinispan-dev] Distributed Counter Discussion
In-Reply-To: <5706527F.6040608@redhat.com>
References: <56E70D92.1010206@infinispan.org>
	<E1D724FA-65AD-464F-A3EE-D65057AC4FBB@redhat.com>
	<56FABA94.5010104@infinispan.org>
	<CAFm4XO3rPD60WasjxdzawqQKEd0VTa4Vw5As0urah1RDP9++Pw@mail.gmail.com>
	<5706527F.6040608@redhat.com>
Message-ID: <CAFm4XO2G8nw3vGs8vx1XmsW5UQ5w39LnrSYZu=qJHtM0yqo1Yw@mail.gmail.com>

On 7 April 2016 at 13:28, Tristan Tarrant <ttarrant at redhat.com> wrote:
> I think the main interface definition (as it is) is fine, but it needs
> to be subclassed into two different behaviours:
>
> - "sync": the value returned by the CF is consistent across the cluster
> - "eventually consistent": the value returned by the CF might be stale
> (maybe return its latest "localh" value)

For the "eventually consistent" case, returning a local value might be
fine but you'd need to define also how writes are merged and what
guarantees it aims to provide (or which we want to intentionally
ignore).

And what about the sequence use case? I guess it can wait, just
tracking the need for that too.

Thanks,
Sanne

>
> Tristan
>
> On 30/03/2016 12:34, Sanne Grinovero wrote:
>> Hi Pedro,
>> there have been many questions on this thread pointing out the need to
>> clarify the definition and which requirements it aims to solve. I
>> don't think we can comment on the API proposal without making that
>> clear first?
>>
>> It seems there was some consensus that this doesn't help for the
>> APIMan use case; could we clarify the goal and use cases then?
>>
>> thanks,
>> Sanne
>>
>> On 29 March 2016 at 18:25, Pedro Ruivo <pedro at infinispan.org> wrote:
>>> == Status update ==
>>>
>>> Hi all,
>>>
>>> The work in progress can be found in [1].
>>>
>>> The main interface is:
>>>
>>> CompletableFuture<Long> addAndGet(long)
>>>
>>> The CompletableFuture will allow to cover a more use cases, for example,
>>> if you need to count the number of visits, you can increment without
>>> waiting it to complete. On other hand, if you need "unique ids", it is
>>> possible to increment and wait for the result.
>>>
>>> * Let me know any concerns with it.
>>>
>>> Currently, two types of counters can be returned by the counter manager:
>>> "unlimited" and limited (i.e. with thresholds).
>>>
>>> "Unlimited" is actually limited to Long.MAX_VALUE but will never throw
>>> any exception when reached.
>>> The limited version throws a CounterException when the min or max
>>> threshold is reached.
>>> In both cases, it doesn't overflow the counter value.
>>>
>>> Currently, I'm working in the notification mechanism. So, just ignore
>>> that part of the code :)
>>>
>>> Moving to the next problem, I need an opinion how to create the counter
>>> manager.
>>>
>>> The current implementation is using a private cache. It has the
>>> advantage of starting the cache when a cache manager starts, however, it
>>> is a bit difficult to configure (e.g. persistence). Also, it does not
>>> allow different configuration for the counter (replicated vs
>>> distributed, persisted or not).
>>>
>>> Another alternative, it to construct the counter manager with the cache
>>> manager and a cache name. This looks simpler and it allows the user to
>>> configure it properly and have different counter manager with different
>>> configurations.
>>>
>>> * Comments are welcome.
>>>
>>> Cheers,
>>> Pedro
>>>
>>> [1] https://github.com/pruivo/infinispan/tree/t_counters/distributed-counter
>>> _______________________________________________
>>> 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  Thu Apr  7 09:12:06 2016
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Thu, 7 Apr 2016 15:12:06 +0200
Subject: [infinispan-dev] Distributed Counter Discussion
In-Reply-To: <CAFm4XO2G8nw3vGs8vx1XmsW5UQ5w39LnrSYZu=qJHtM0yqo1Yw@mail.gmail.com>
References: <56E70D92.1010206@infinispan.org>
	<E1D724FA-65AD-464F-A3EE-D65057AC4FBB@redhat.com>
	<56FABA94.5010104@infinispan.org>
	<CAFm4XO3rPD60WasjxdzawqQKEd0VTa4Vw5As0urah1RDP9++Pw@mail.gmail.com>
	<5706527F.6040608@redhat.com>
	<CAFm4XO2G8nw3vGs8vx1XmsW5UQ5w39LnrSYZu=qJHtM0yqo1Yw@mail.gmail.com>
Message-ID: <57065CA6.7000109@redhat.com>

On 07/04/2016 15:06, Sanne Grinovero wrote:
> For the "eventually consistent" case, returning a local value might be
> fine but you'd need to define also how writes are merged and what
> guarantees it aims to provide (or which we want to intentionally
> ignore)

Fortunately a counter has commutative ops, so order is unimportant and 
it makes things so much easier ;)

> And what about the sequence use case? I guess it can wait, just
> tracking the need for that too.

Yes, that is a separate thing as it needs far stricter guarantees.

Tristan

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

From dan.berindei at gmail.com  Thu Apr  7 12:56:13 2016
From: dan.berindei at gmail.com (Dan Berindei)
Date: Thu, 7 Apr 2016 19:56:13 +0300
Subject: [infinispan-dev] Should Tree module be deprecated?
In-Reply-To: <57065096.6040702@redhat.com>
References: <E1F85DCC-124E-48FD-AC63-38D91E2D9BDE@redhat.com>
	<CA+YCuUNjO5WP+6ELJR8Es6MUkD+ApX13KrZjhyarTkaaXTyvng@mail.gmail.com>
	<57065096.6040702@redhat.com>
Message-ID: <CA+nfvwSQO2sQqHgi6n9Ar0bgjrsWQhJ6Hbj+zvuG1vTK17bF7A@mail.gmail.com>

+1 to deprecate it, then we can deprecate AtomicHashMap as well :)

OTOH the scenario in the question seems really basic, we should have
some distributed mode tests to cover it, even if we decide to
deprecate the module.

Dan


On Thu, Apr 7, 2016 at 3:20 PM, Tristan Tarrant <ttarrant at redhat.com> wrote:
> We should really try to understand the reason why people want a
> treecache. If it is just for ease of porting from JBossCache, then we
> should write an article detailing different strategies on migrating to
> the Map before we proceed with the deprecation (although I'm strongly in
> favour of it).
>
> Tristan
>
> On 01/04/2016 18:47, William Burns wrote:
>> I think we should at least deprecate it for 9.0, if not totally remove
>> it (although I understand we probably can't remove it yet)
>>
>> TreeCache seems to pop up a lot with people complaining about it.
>>
>>   - Will
>>
>> On Tue, Mar 29, 2016 at 3:48 AM Galder Zamarre?o <galder at redhat.com
>> <mailto:galder at redhat.com>> wrote:
>>
>>     Re:
>>     http://stackoverflow.com/questions/29673123/infinispan-treecache-not-getting-distributed-properly?noredirect=1#comment59906993_29673123
>>
>>     Cheers,
>>     --
>>     Galder Zamarre?o
>>     Infinispan, 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
>>
>>
>>
>> _______________________________________________
>> 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 sanne at infinispan.org  Mon Apr 11 18:22:33 2016
From: sanne at infinispan.org (Sanne Grinovero)
Date: Mon, 11 Apr 2016 23:22:33 +0100
Subject: [infinispan-dev] Distributed Executor remote cancellation
In-Reply-To: <56FC1BBD.4020102@redhat.com>
References: <CA+YCuUNeHaybZ-5t4NvE6Yiv5n7+j0mTck2BDj0-WneFYNsJrg@mail.gmail.com>
	<CAFm4XO3tMVX6aeVn0jjAuDmi8nTDO35+2hnGZ=v-tpSW9+4Uqg@mail.gmail.com>
	<56FBFEEF.2030702@redhat.com>
	<CA+YCuUNDLRKKq_psh4r8PGM18Bym_UaWkpM8o=wtza-yZp8x5A@mail.gmail.com>
	<CAFm4XO2o5qqXEa2oR3WwwE5v+=GTUf2-s60Qyzuf1r4tp6uDoA@mail.gmail.com>
	<56FC1BBD.4020102@redhat.com>
Message-ID: <CAFm4XO1=qEJzQDbM2up6zv-H91se2MVVBm121OLMTSZzOZQ07w@mail.gmail.com>

On 30 March 2016 at 19:32, Dennis Reed <dereed at redhat.com> wrote:
> On 03/30/2016 12:26 PM, Sanne Grinovero wrote:
>> On 30 March 2016 at 17:40, William Burns <mudokonman at gmail.com> wrote:
>>> You can still attempt to cancel a task.  This email is specifically about
>>> interruption though.  Let me explain the nuances in a bit more detail.
>>>
>>> With the suggestion we would still fully support if the task hasn't yet
>>> started that it would be cancellable.
>>>
>>> However when you cancel a task, there is an mayInterruptIfRunning boolean.
>>> If mayInterruptIfRunning is true and the task is already running it will try
>>> to interrupt the thread processing it.  This is what this email trail is
>>> about.  We all know that java interruption can be flaky to begin with and
>>> then adding a remote aspect to it, it becomes even more unreliable.
>>>
>>> So do you guys think we need to support "interrupting" a task in progress?
>>
>> Yes, absolutely! Resources are precious :)
>>
>> See also the reasoning of our old friend:
>>   - https://corner.squareup.com/2016/01/query-sniper.html
>>
>> Take the example of a non-correctly tuned Hibernate Search "rebuild
>> all indexes" task. On a non-trivial data set it might need to run for
>> weeks... you need a way to kill it.
>
> Do you want a way to "kill" it, or a way to "interrupt" it?  Your reply
> appeared to equate these, but the terms are actually quite different.
>
> Interruption is more of a "hey, if you don't mind could you please
> stop?", and requires the code to correctly handle it.  The vast majority
> of code isn't written with interruption in mind.

Great point Dennis, thanks. I had our own implemented tasks in mind -
like the indexer which is built on top of this - for which we can
implement an appropriate termination and name the method "cancel
indexing" at higher level but you're right we can not guarantee
termination of user code.

> As William mentioned, interruption is not reliable (and there isn't any
> reliable and safe way to stop a single thread in Java).  So the question
> is whether we want to support "ask it to stop, and it might stop or it
> might not" functionality.

+1 we'll have to ask.

I suspect we could find some ways to kill it at certain specific
points, i.e. when it invokes a method on the Cache, but I agree
there's no safe way to do so reliably. So, would it be worth to
attempt to kill it? I guess not.

Thanks,
Sanne

>
> -Dennis
>
>
>> Thanks,
>> Sanne
>>
>>>
>>>   - Will
>>>
>>> On Wed, Mar 30, 2016 at 12:29 PM Tristan Tarrant <ttarrant at redhat.com>
>>> wrote:
>>>>
>>>> I agree with Sanne, we need cancellable  tasks.
>>>>
>>>> Tristan
>>>>
>>>> On 30/03/2016 18:19, Sanne Grinovero wrote:
>>>>> The term "Interruption" might have been too specific, but being able
>>>>> to cancel a task seems essential to me.
>>>>>
>>>>> On 30 March 2016 at 17:04, William Burns <mudokonman at gmail.com> wrote:
>>>>>> Recently we have been moving a lot of our methods that return Future
>>>>>> [1] to
>>>>>> CompletableFuture [2].  Unfortunately the latter, CompletableFuture,
>>>>>> doesn't
>>>>>> allow for cancellation of the future, since there is no thread tied to
>>>>>> it.
>>>>>> So I am proposing that our DistributedExecutorService [3] no longer
>>>>>> allows
>>>>>> for interruption of remote threads on a cancellation.  This way we can
>>>>>> have
>>>>>> our distributed executor service return CompletableFuture instances
>>>>>> which do
>>>>>> not support interruption.
>>>>>>
>>>>>> Also to note that DistributedExecutorService extends ExecutorService
>>>>>> which
>>>>>> returns a normal Future which is documented as allowing cancellation.
>>>>>> In
>>>>>> this case I would just document on DistributedExecutorService that we
>>>>>> don't
>>>>>> support interruption anyways.
>>>>>>
>>>>>> Does anyone require the use of interruptable tasks with Distributed
>>>>>> Executor?
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>>    - Will
>>>>>>
>>>>>> [1]
>>>>>>
>>>>>> https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Future.html
>>>>>> [2]
>>>>>>
>>>>>> https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html
>>>>>> [3]
>>>>>>
>>>>>> https://docs.jboss.org/infinispan/8.1/apidocs/org/infinispan/distexec/DistributedExecutorService.html
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>> _______________________________________________
>> 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 Apr 11 18:28:57 2016
From: sanne at infinispan.org (Sanne Grinovero)
Date: Mon, 11 Apr 2016 23:28:57 +0100
Subject: [infinispan-dev] Distributed Executor remote cancellation
In-Reply-To: <CA+nfvwRVuD_uzEWdTMpcQdd+ufkFdLMiXRmJvE=HNgbguX=n3w@mail.gmail.com>
References: <CA+YCuUNeHaybZ-5t4NvE6Yiv5n7+j0mTck2BDj0-WneFYNsJrg@mail.gmail.com>
	<CAFm4XO3tMVX6aeVn0jjAuDmi8nTDO35+2hnGZ=v-tpSW9+4Uqg@mail.gmail.com>
	<56FBFEEF.2030702@redhat.com>
	<CA+YCuUNDLRKKq_psh4r8PGM18Bym_UaWkpM8o=wtza-yZp8x5A@mail.gmail.com>
	<CAFm4XO2o5qqXEa2oR3WwwE5v+=GTUf2-s60Qyzuf1r4tp6uDoA@mail.gmail.com>
	<CAH8Ud1EycQQYZ+2ktRPbHaUccAKM1pL14gwWWVkDoZ02vEYg3A@mail.gmail.com>
	<CA+YCuUPffKxYePPvfp+ftfWW2W+G746Va2Z0Wuo9zKn_qEc43Q@mail.gmail.com>
	<56FCD0BE.7020803@redhat.com>
	<CA+nfvwRVuD_uzEWdTMpcQdd+ufkFdLMiXRmJvE=HNgbguX=n3w@mail.gmail.com>
Message-ID: <CAFm4XO1=4Q9BbzY73MYxwJ2YhG1KR0ok=kQrDiSPxMTztN4srQ@mail.gmail.com>

On 31 March 2016 at 13:31, Dan Berindei <dan.berindei at gmail.com> wrote:
> On Thu, Mar 31, 2016 at 10:24 AM, Radim Vansa <rvansa at redhat.com> wrote:
>> Can any of the chained futures be already running when the first is not
>> completed? Because when it's not running, there's nothing to interrupt.
>
> It's not a matter of timing, but the CF instance returned by any CF
> method will not pass the cancellation request to the initial future.
> So this code won't cancel anything:
>
>       CompletableFuture<Void> cf =
> CompletableFuture.allOf(des.submitEverywhere(() -> null).toArray(new
> CompletableFuture[0]));
>       cf.cancel(true);
>
>>
>> Btw., if the interface returns CompletableFuture but you inherit from
>> that to override the cancel method, the javadoc will still say that the
>> mayInterruptIfRunning does not apply. In that case, you should either
>> return InterruptableCompletableFuture with javadoc override, or maybe
>> just AnotherFuture implements Future, CompletionStage (names at your
>> discretion).
>
> Yeah, we should also make it clear that remote tasks are interrupted
> -- we know that's how it used to work, but it wasn't documented.
>
>>
>> R.
>>
>> On 03/30/2016 08:13 PM, William Burns wrote:
>>> Thanks for the feedback.
>>>
>>> So in that case to try to appease both worlds: interrupting tasks and
>>> using CompletableFuture, I will just document the
>>> DistributedExecutorService to say that the mayInterruptIfRunning
>>> argument is only used on the returned future instance from methods
>>> such as submit and it is ignored on any chained CompletableFutures.
>>>
>>>  - Will
>>>
>>> On Wed, Mar 30, 2016 at 1:37 PM Gustavo Fernandes
>>> <gustavo at infinispan.org <mailto:gustavo at infinispan.org>> wrote:
>>>
>>>     On Wed, Mar 30, 2016 at 6:26 PM, Sanne Grinovero
>>>     <sanne at infinispan.org <mailto:sanne at infinispan.org>> wrote:
>>>
>>>         On 30 March 2016 at 17:40, William Burns <mudokonman at gmail.com
>>>         <mailto:mudokonman at gmail.com>> wrote:
>>>         > You can still attempt to cancel a task. This email is
>>>         specifically about
>>>         > interruption though.  Let me explain the nuances in a bit
>>>         more detail.
>>>         >
>>>         > With the suggestion we would still fully support if the task
>>>         hasn't yet
>>>         > started that it would be cancellable.
>>>         >
>>>         > However when you cancel a task, there is an
>>>         mayInterruptIfRunning boolean.
>>>         > If mayInterruptIfRunning is true and the task is already
>>>         running it will try
>>>         > to interrupt the thread processing it. This is what this
>>>         email trail is
>>>         > about.  We all know that java interruption can be flaky to
>>>         begin with and
>>>         > then adding a remote aspect to it, it becomes even more
>>>         unreliable.
>>>         >
>>>         > So do you guys think we need to support "interrupting" a
>>>         task in progress?
>>>
>>>         Yes, absolutely! Resources are precious :)
>>>
>>>         See also the reasoning of our old friend:
>>>          - https://corner.squareup.com/2016/01/query-sniper.html
>>>
>>>         Take the example of a non-correctly tuned Hibernate Search
>>>         "rebuild
>>>         all indexes" task. On a non-trivial data set it might need to
>>>         run for
>>>         weeks... you need a way to kill it.
>>>
>>>
>>>
>>>     That's the case of our Mass Indexer: one of the motivations of
>>>     making it return a Future was
>>>     the possibility of cancelling tasks, capability offered by the
>>>     Distributed Executor.
>
> Could you expand a bit on when you need to interrupt the indexer?

Scenario: you triggered the indexer, then after two hours it reports
"1% complete, 5 days estimated to completion".

At that point you realize your tuning options are wrong, and setting
the write buffer size to the production settings rather than keeping
the "hello world" setting which you used during a POC might save you 5
days.. so you'd like to stop this and restart with different options.

Now if you can cancel it, it's easy.. but if the alternative is taking
down the cluster and then have to re-import all data or reload it all
from cachestores that's quite annoying.

Cheers,
Sanne

>
> Note that cancel(true) doesn't/didn't do anything if the future is
> already done (e.g. because the replication timeout expired). So when
> it comes to handling timeouts, it's always better to do it in the task
> itself.
>
> Cheers
> Dan
>
>
>>>
>>>     Gustavo
>>>
>>>
>>>         Thanks,
>>>         Sanne
>>>
>>>         >
>>>         >  - Will
>>>         >
>>>         > On Wed, Mar 30, 2016 at 12:29 PM Tristan Tarrant
>>>         <ttarrant at redhat.com <mailto:ttarrant at redhat.com>>
>>>         > wrote:
>>>         >>
>>>         >> I agree with Sanne, we need cancellable  tasks.
>>>         >>
>>>         >> Tristan
>>>         >>
>>>         >> On 30/03/2016 18:19, Sanne Grinovero wrote:
>>>         >> > The term "Interruption" might have been too specific, but
>>>         being able
>>>         >> > to cancel a task seems essential to me.
>>>         >> >
>>>         >> > On 30 March 2016 at 17:04, William Burns
>>>         <mudokonman at gmail.com <mailto:mudokonman at gmail.com>> wrote:
>>>         >> >> Recently we have been moving a lot of our methods that
>>>         return Future
>>>         >> >> [1] to
>>>         >> >> CompletableFuture [2]. Unfortunately the latter,
>>>         CompletableFuture,
>>>         >> >> doesn't
>>>         >> >> allow for cancellation of the future, since there is no
>>>         thread tied to
>>>         >> >> it.
>>>         >> >> So I am proposing that our DistributedExecutorService
>>>         [3] no longer
>>>         >> >> allows
>>>         >> >> for interruption of remote threads on a cancellation.
>>>         This way we can
>>>         >> >> have
>>>         >> >> our distributed executor service return
>>>         CompletableFuture instances
>>>         >> >> which do
>>>         >> >> not support interruption.
>>>         >> >>
>>>         >> >> Also to note that DistributedExecutorService extends
>>>         ExecutorService
>>>         >> >> which
>>>         >> >> returns a normal Future which is documented as allowing
>>>         cancellation.
>>>         >> >> In
>>>         >> >> this case I would just document on
>>>         DistributedExecutorService that we
>>>         >> >> don't
>>>         >> >> support interruption anyways.
>>>         >> >>
>>>         >> >> Does anyone require the use of interruptable tasks with
>>>         Distributed
>>>         >> >> Executor?
>>>         >> >>
>>>         >> >> Thanks,
>>>         >> >>
>>>         >> >>   - Will
>>>         >> >>
>>>         >> >> [1]
>>>         >> >>
>>>         >> >>
>>>         https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Future.html
>>>         >> >> [2]
>>>         >> >>
>>>         >> >>
>>>         https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html
>>>         >> >> [3]
>>>         >> >>
>>>         >> >>
>>>         https://docs.jboss.org/infinispan/8.1/apidocs/org/infinispan/distexec/DistributedExecutorService.html
>>>         >> >>
>>>         >> >> _______________________________________________
>>>         >> >> 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
>>>         >> >
>>>         >>
>>>         >> --
>>>         >> 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
>>>         >
>>>         >
>>>         > _______________________________________________
>>>         > 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 <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
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

From ugo.landini at gmail.com  Tue Apr 12 05:04:41 2016
From: ugo.landini at gmail.com (ugol)
Date: Tue, 12 Apr 2016 11:04:41 +0200
Subject: [infinispan-dev] Go hotrod client for Infinispan
Message-ID: <CAAis47XHEBi=1UW=ma7ELEBGpfVqOGqqZMz-Ofuq7s7cDah_1g@mail.gmail.com>

Hi guys,
I have implemented just get and posts operations at the moment but
hopefully with all bells & whistles:

- 2.5 protocol
- lifespan & expiration as optional parameters with multiple time units
- named caches
- previous values options
- error handling
- "full" test suite

https://github.com/ugol/infinispan-go/

if you don't see anything blatantly wrong, I can easily complete all
L1 hotrod operations, write a bit of documentation and then start the
implementation of L2/L3

if you want to test it, just run an 8.2 server and a "go test -v".
Sometimes you can see an error due to a race condition in the tests
for the message ids, didn't have the time to fix it

ciao
-- 
uL

Pragmatist
http://blog.ugolandini.com
http://www.flickr.com/photos/ugol/

From vrigamon at redhat.com  Wed Apr 13 04:45:19 2016
From: vrigamon at redhat.com (Vittorio Rigamonti)
Date: Wed, 13 Apr 2016 04:45:19 -0400 (EDT)
Subject: [infinispan-dev] Release 9.0.0.Alpha1 is out!
In-Reply-To: <1614082818.9683345.1460532827452.JavaMail.zimbra@redhat.com>
Message-ID: <1561955191.9745005.1460537119617.JavaMail.zimbra@redhat.com>

Hi Infinispan Devs,

I'm pleased to announce that the first release of the 9 serie is out.

http://blog.infinispan.org/2016/04/infinispan-900alpha1-is-out.html

It's an Alpha so enjoy it.

Cheers,
Vittorio


From rory.odonnell at oracle.com  Fri Apr 15 04:37:33 2016
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Fri, 15 Apr 2016 09:37:33 +0100
Subject: [infinispan-dev] Early Access builds of JDK 9 b113 & JDK 9 with
 Project Jigsaw b113 (#4848) are available on java.net
Message-ID: <5710A84D.9040802@oracle.com>


Hi Galder,

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

Early Access b113 <https://jdk9.java.net/jigsaw/> (#4664) for JDK 9 with 
Project Jigsaw is available on java.net.

  * The important change in this build is that root modules when
    compiling code in the unnamed module, or when running and the main
    class is loaded from the class path, do not include the EE modules.
    More on this in JEP 261.
  * The other change in this build is that the -Xpatch option is now
    aligned with what we have documented in JEP 261, support for the old
    form has been removed.

We are very interested in hearing your experiences in testing any Early 
Access builds. Have you have begun testing against
JDK 9 and or JDK 9 with Project Jigsaw EA builds, have you uncovered 
showstopper issues that you would like to discuss?
We would really like to hear your findings so far, either reply to me or 
via the mailing lists [1], [2].

Rgds,Rory

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/
[2] http://mail.openjdk.java.net/pipermail/jdk9-dev/

-- 
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/20160415/974b73f7/attachment.html 

From ttarrant at redhat.com  Mon Apr 18 14:54:34 2016
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Mon, 18 Apr 2016 20:54:34 +0200
Subject: [infinispan-dev] Weekly Infinispan IRC Meeting 2016-04-18
Message-ID: <57152D6A.3050305@redhat.com>

Hi all,

the logs of the weekly meeting are at

http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2016/infinispan.2016-04-18-13.29.log.html


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

From galder at redhat.com  Tue Apr 19 12:31:57 2016
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Tue, 19 Apr 2016 18:31:57 +0200
Subject: [infinispan-dev] Remote execute null return (ISPN-6406)
Message-ID: <2F1C43D9-BB1F-4E5D-98B8-36208AFE5DF7@redhat.com>

Hi all,

A Hot Rod protocol change might be required as a result of [1].

In essence, the Hot Rod protocol does not specify how remote exec calls that return null should respond back to the client [2].

Returning an empty byte[] won't cut it since returning an empty String would be represented that way, and that's different to null.

I don't know how this could be handled without modifying the protocol, any ideas?

If modifying the protocol, adding a new status code would be a way to handle it.

Thoughts?

[1] https://issues.jboss.org/browse/ISPN-6406
[2] http://infinispan.org/docs/8.2.x/user_guide/user_guide.html#_hot_rod_protocol_2_0
--
Galder Zamarre?o
Infinispan, Red Hat



From slaskawi at redhat.com  Tue Apr 19 17:16:53 2016
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Tue, 19 Apr 2016 23:16:53 +0200
Subject: [infinispan-dev] The final part of CDI split
Message-ID: <CAA9R9O4RgV103MSZHk211X7oC9o8XFaKn3qCXB+pPa=8CDJjeA@mail.gmail.com>

Hey!

In Infinispan 8 series we split CDI into common, remote and embedded. In
order to preserve backwards compatibility we decided to leave embedded and
common code in "org.infinispan.cdi" package. See [1] for more details.

Now in Infinispan 9 I'm planning to move the bits to proper packages as
proposed in [2]. Since CDI does most of the job behind the scenes, most of
the use cases will preserve backwards compatibility apart from using
embedded CDI extension from JBoss Modules. In that case one will need to
change his dependency in MANIFEST.MF (or deployment-structure.xml) from
"org.infinispan.cdi" to "org.infinispan.cdi.embedded", which is more
descriptive in my opinion.

Does anyone has any arguments against this change?

Thanks
Sebastian

[1]
https://github.com/infinispan/infinispan/pull/4249#issuecomment-211910849
[2] https://github.com/infinispan/infinispan/pull/4249
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160419/4840f848/attachment.html 

From slaskawi at redhat.com  Wed Apr 20 11:00:16 2016
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Wed, 20 Apr 2016 17:00:16 +0200
Subject: [infinispan-dev] Remote execute null return (ISPN-6406)
In-Reply-To: <2F1C43D9-BB1F-4E5D-98B8-36208AFE5DF7@redhat.com>
References: <2F1C43D9-BB1F-4E5D-98B8-36208AFE5DF7@redhat.com>
Message-ID: <CAA9R9O7b_L-fZ_rnA191HC_tXijMT5OnVh9XQX=8r3h6pm+f9g@mail.gmail.com>

I think this is pretty common problem [3].

On the other hand most of the users won't be interested in distinguishing
nulls from empty strings (at least in my opinion). So how about leaving it
as is by default and creating some configuration parameter for using new
status code as you suggested (just in case someone would have to
distinguish those two).

This way we would be somewhat backwards compatible and we would have a
rescue option for some users who would need this feature.

[3] http://blog.bdoughan.com/2012/04/binding-to-json-xml-handling-null.html

On Tue, Apr 19, 2016 at 6:31 PM, Galder Zamarre?o <galder at redhat.com> wrote:

> Hi all,
>
> A Hot Rod protocol change might be required as a result of [1].
>
> In essence, the Hot Rod protocol does not specify how remote exec calls
> that return null should respond back to the client [2].
>
> Returning an empty byte[] won't cut it since returning an empty String
> would be represented that way, and that's different to null.
>
> I don't know how this could be handled without modifying the protocol, any
> ideas?
>
> If modifying the protocol, adding a new status code would be a way to
> handle it.
>
> Thoughts?
>
> [1] https://issues.jboss.org/browse/ISPN-6406
> [2]
> http://infinispan.org/docs/8.2.x/user_guide/user_guide.html#_hot_rod_protocol_2_0
> --
> Galder Zamarre?o
> Infinispan, 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/20160420/fa46d6f8/attachment.html 

From dereed at redhat.com  Wed Apr 20 17:53:49 2016
From: dereed at redhat.com (Dennis Reed)
Date: Wed, 20 Apr 2016 14:53:49 -0700
Subject: [infinispan-dev] Remote execute null return (ISPN-6406)
In-Reply-To: <CAA9R9O7b_L-fZ_rnA191HC_tXijMT5OnVh9XQX=8r3h6pm+f9g@mail.gmail.com>
References: <2F1C43D9-BB1F-4E5D-98B8-36208AFE5DF7@redhat.com>
	<CAA9R9O7b_L-fZ_rnA191HC_tXijMT5OnVh9XQX=8r3h6pm+f9g@mail.gmail.com>
Message-ID: <5717FA6D.7060302@redhat.com>

A related question -- do you want to support null in the protocol?  Not
all languages even have a concept of null.

So you do need to make a decision whether to support null to the
exclusion of languages that don't have it (or make Hot Rod more
complicated to use in those languages), or disallow null to increase
interoperability but with a restriction of functionality in those
languages that do allow it.

-Dennis


On 04/20/2016 08:00 AM, Sebastian Laskawiec wrote:
> I think this is pretty common problem [3]. 
> 
> On the other hand most of the users won't be interested in
> distinguishing nulls from empty strings (at least in my opinion). So how
> about leaving it as is by default and creating some configuration
> parameter for using new status code as you suggested (just in case
> someone would have to distinguish those two).
> 
> This way we would be somewhat backwards compatible and we would have a
> rescue option for some users who would need this feature.
> 
> [3] http://blog.bdoughan.com/2012/04/binding-to-json-xml-handling-null.html
> 
> On Tue, Apr 19, 2016 at 6:31 PM, Galder Zamarre?o <galder at redhat.com
> <mailto:galder at redhat.com>> wrote:
> 
>     Hi all,
> 
>     A Hot Rod protocol change might be required as a result of [1].
> 
>     In essence, the Hot Rod protocol does not specify how remote exec
>     calls that return null should respond back to the client [2].
> 
>     Returning an empty byte[] won't cut it since returning an empty
>     String would be represented that way, and that's different to null.
> 
>     I don't know how this could be handled without modifying the
>     protocol, any ideas?
> 
>     If modifying the protocol, adding a new status code would be a way
>     to handle it.
> 
>     Thoughts?
> 
>     [1] https://issues.jboss.org/browse/ISPN-6406
>     [2]
>     http://infinispan.org/docs/8.2.x/user_guide/user_guide.html#_hot_rod_protocol_2_0
>     --
>     Galder Zamarre?o
>     Infinispan, 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
> 
> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 


From galder at redhat.com  Thu Apr 21 04:07:33 2016
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Thu, 21 Apr 2016 10:07:33 +0200
Subject: [infinispan-dev] Potential for context object for serial/deserial
	in marshalling rework
Message-ID: <198F7FB4-BF9A-4EF6-9638-1531975F2EEA@redhat.com>

Hey guys,

Just a quick heads up about [1].

As I was looking at the marshalling code in core, I spotted the work done for [2] and by extension [3].

I can certainly see the practicality of Will's solution in [2] which fitted quite well with the current marshalling architecture, but as we rethink the entire marshalling layer in [1], I'm wondering if a context-object where we can track repeated fields like Strings, Addresses... would be more suitable. For starters, we'd get rid of thread locals and could be more easily exposed in other places.

Any ideas or updates you have on the topic please let me know.

Cheers,

[1] https://issues.jboss.org/browse/ISPN-6498
[2] https://issues.jboss.org/browse/ISPN-4979
[3] https://issues.jboss.org/browse/ISPN-2133
--
Galder Zamarre?o
Infinispan, Red Hat



From ttarrant at redhat.com  Thu Apr 21 04:18:02 2016
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Thu, 21 Apr 2016 10:18:02 +0200
Subject: [infinispan-dev] Potential for context object for
 serial/deserial in marshalling rework
In-Reply-To: <198F7FB4-BF9A-4EF6-9638-1531975F2EEA@redhat.com>
References: <198F7FB4-BF9A-4EF6-9638-1531975F2EEA@redhat.com>
Message-ID: <57188CBA.8000302@redhat.com>

On a related aspect,

could this context object also hold security-related information ? 
Currently the "lightweight" security uses a ThreadLocal to avoid going 
through the AccessControlContext (which, is painfully slow), but I'd 
prefer a "context" approach.

Tristan

On 21/04/2016 10:07, Galder Zamarre?o wrote:
> Hey guys,
>
> Just a quick heads up about [1].
>
> As I was looking at the marshalling code in core, I spotted the work done for [2] and by extension [3].
>
> I can certainly see the practicality of Will's solution in [2] which fitted quite well with the current marshalling architecture, but as we rethink the entire marshalling layer in [1], I'm wondering if a context-object where we can track repeated fields like Strings, Addresses... would be more suitable. For starters, we'd get rid of thread locals and could be more easily exposed in other places.
>
> Any ideas or updates you have on the topic please let me know.
>
> Cheers,
>
> [1] https://issues.jboss.org/browse/ISPN-6498
> [2] https://issues.jboss.org/browse/ISPN-4979
> [3] https://issues.jboss.org/browse/ISPN-2133
> --
> Galder Zamarre?o
> Infinispan, Red Hat
>
>
> _______________________________________________
> 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 galder at redhat.com  Thu Apr 21 04:35:08 2016
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Thu, 21 Apr 2016 10:35:08 +0200
Subject: [infinispan-dev] Potential for context object for
	serial/deserial in marshalling rework
In-Reply-To: <198F7FB4-BF9A-4EF6-9638-1531975F2EEA@redhat.com>
References: <198F7FB4-BF9A-4EF6-9638-1531975F2EEA@redhat.com>
Message-ID: <65F0A44E-DACC-470E-9DBE-F98F8652DF9E@redhat.com>

For example, I'd like to get some clarification on the scope of the context object:

@Will, will the solution you provided in [2] deal with multiple JGroups marshalling request callbacks? Or is it only designed for a single marshalling request callback coming from JGroups tgat contains a CacheStatusResponse map? Since it's a thread local is not easy to see what's the lifespan of these instances stored in the thread local...

The simplest thing would be to have a new context created for each JGroups marshalling request.

However, more optimizations could be achieved from:

1. For non-transaction operations, a context per operation. So if a cache.put() results in two operations being serialized (get to return previous value, and put itself), then the context could expand those two serializations.

2. For transaction operations, a context per transaction.

@Sanne, would this be enough for you? In your [4] dev post you seem to want to go beyond marshalling into how we'd keep references of objects in memory, e.g. if a String is repeated in many places, have a way to centralise that storage in memory itself.

Cheers,

[4] http://lists.jboss.org/pipermail/infinispan-dev/2012-June/010925.html
--
Galder Zamarre?o
Infinispan, Red Hat

> On 21 Apr 2016, at 10:07, Galder Zamarre?o <galder at redhat.com> wrote:
> 
> Hey guys,
> 
> Just a quick heads up about [1].
> 
> As I was looking at the marshalling code in core, I spotted the work done for [2] and by extension [3].
> 
> I can certainly see the practicality of Will's solution in [2] which fitted quite well with the current marshalling architecture, but as we rethink the entire marshalling layer in [1], I'm wondering if a context-object where we can track repeated fields like Strings, Addresses... would be more suitable. For starters, we'd get rid of thread locals and could be more easily exposed in other places.
> 
> Any ideas or updates you have on the topic please let me know.
> 
> Cheers,
> 
> [1] https://issues.jboss.org/browse/ISPN-6498
> [2] https://issues.jboss.org/browse/ISPN-4979
> [3] https://issues.jboss.org/browse/ISPN-2133
> --
> Galder Zamarre?o
> Infinispan, Red Hat
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev



From sanne at infinispan.org  Thu Apr 21 06:55:36 2016
From: sanne at infinispan.org (Sanne Grinovero)
Date: Thu, 21 Apr 2016 12:55:36 +0200
Subject: [infinispan-dev] Potential for context object for
 serial/deserial in marshalling rework
In-Reply-To: <65F0A44E-DACC-470E-9DBE-F98F8652DF9E@redhat.com>
References: <198F7FB4-BF9A-4EF6-9638-1531975F2EEA@redhat.com>
	<65F0A44E-DACC-470E-9DBE-F98F8652DF9E@redhat.com>
Message-ID: <CAFm4XO01ZQ9Zqky72Sci2S1CHPYGjFUx80Evm-Pe2z-amYeYMA@mail.gmail.com>

Hey Galder,
these "scopes" you mention sound cool, but I'm afraid you'd end up
designing a user friendly API more than allowing the level of
performance optimisations we need.

If we pass a "context" map, or eventually make it a map of maps when
you'll figure you have nested structures such as [object type, object
id], then:
 - each deserialization event will need to perform multiple
[concurrent]Map lookups
 - I wouldn't be able to plug in an ad-hoc data structure: e.g. Will's
"instance" strategy seems efficient :)
 - we'll need to implement size-capping strategies, i.e. these would
need to support eviction strategies, not least configuration options
for such eviction.
 - similar cost traversing multiple [concurrent]Map to write to the
"context cache"

I would suggest instead to give more flexibility to custom
Externalizer implementors by making them stateful: if you could allow
them to have something akin to the ComponentRegistry injected within
the constructor, then a power user could pre-register custom services,
look them up only once during construction, and then benefit from the
performance of final field reads, from ad-hoc optimised containers.
The implementor would also be fully responsible of making a reasonable
choice to cap size.

The complexity is then to make sure the components are booted in the
right order, and that the Externalizer instance is bound to the right
scope.
I realize that the Externalizer chain needs to be booted early, but
the services it would look up are unlikely to need anything else so it
shouldn't be hard to figure a reasonable order for bootsrapping these
components.

For example, one complexity would be that an Externalizer instance
which is bound to cache-specific services can not be part of an
externalizer chain used for a different Cache, but I believe this is
in place already because of the classloader requirements.

WDYT, is this feasible? I realize it makes it harder to use, but then
again I expect such tricks to be applied only by internal component
and expert-level extensions (i.e. Hibernate OGM, Lucene, etc..).

Thanks,
Sanne

On 21 April 2016 at 10:35, Galder Zamarre?o <galder at redhat.com> wrote:
> For example, I'd like to get some clarification on the scope of the context object:
>
> @Will, will the solution you provided in [2] deal with multiple JGroups marshalling request callbacks? Or is it only designed for a single marshalling request callback coming from JGroups tgat contains a CacheStatusResponse map? Since it's a thread local is not easy to see what's the lifespan of these instances stored in the thread local...
>
> The simplest thing would be to have a new context created for each JGroups marshalling request.
>
> However, more optimizations could be achieved from:
>
> 1. For non-transaction operations, a context per operation. So if a cache.put() results in two operations being serialized (get to return previous value, and put itself), then the context could expand those two serializations.
>
> 2. For transaction operations, a context per transaction.
>
> @Sanne, would this be enough for you? In your [4] dev post you seem to want to go beyond marshalling into how we'd keep references of objects in memory, e.g. if a String is repeated in many places, have a way to centralise that storage in memory itself.
>
> Cheers,
>
> [4] http://lists.jboss.org/pipermail/infinispan-dev/2012-June/010925.html
> --
> Galder Zamarre?o
> Infinispan, Red Hat
>
>> On 21 Apr 2016, at 10:07, Galder Zamarre?o <galder at redhat.com> wrote:
>>
>> Hey guys,
>>
>> Just a quick heads up about [1].
>>
>> As I was looking at the marshalling code in core, I spotted the work done for [2] and by extension [3].
>>
>> I can certainly see the practicality of Will's solution in [2] which fitted quite well with the current marshalling architecture, but as we rethink the entire marshalling layer in [1], I'm wondering if a context-object where we can track repeated fields like Strings, Addresses... would be more suitable. For starters, we'd get rid of thread locals and could be more easily exposed in other places.
>>
>> Any ideas or updates you have on the topic please let me know.
>>
>> Cheers,
>>
>> [1] https://issues.jboss.org/browse/ISPN-6498
>> [2] https://issues.jboss.org/browse/ISPN-4979
>> [3] https://issues.jboss.org/browse/ISPN-2133
>> --
>> Galder Zamarre?o
>> Infinispan, 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


From mudokonman at gmail.com  Thu Apr 21 09:06:26 2016
From: mudokonman at gmail.com (William Burns)
Date: Thu, 21 Apr 2016 13:06:26 +0000
Subject: [infinispan-dev] Potential for context object for
 serial/deserial in marshalling rework
In-Reply-To: <65F0A44E-DACC-470E-9DBE-F98F8652DF9E@redhat.com>
References: <198F7FB4-BF9A-4EF6-9638-1531975F2EEA@redhat.com>
	<65F0A44E-DACC-470E-9DBE-F98F8652DF9E@redhat.com>
Message-ID: <CA+YCuUO8UPVRAQBWOEz=oWD=TCU1SEQXk9XdSmEg0ne7jNXpmw@mail.gmail.com>

On Thu, Apr 21, 2016 at 4:35 AM Galder Zamarre?o <galder at redhat.com> wrote:

> For example, I'd like to get some clarification on the scope of the
> context object:
>
> @Will, will the solution you provided in [2] deal with multiple JGroups
> marshalling request callbacks? Or is it only designed for a single
> marshalling request callback coming from JGroups tgat contains a
> CacheStatusResponse map? Since it's a thread local is not easy to see
> what's the lifespan of these instances stored in the thread local...
>

The scope is per object serialization instance (the thread local is always
cleared after each object).  More specifically, the externalizer was meant
to be extended by possibly different classes and the first class in the
marshalling "stack" will set the thread local to have the IdentityMap.  It
then uses that to map objects that have the same instance to be serialized.

JBoss Marshalling does the same thing internally when you don't use an
object table btw.


>
> The simplest thing would be to have a new context created for each JGroups
> marshalling request.
>
> However, more optimizations could be achieved from:
>
> 1. For non-transaction operations, a context per operation. So if a
> cache.put() results in two operations being serialized (get to return
> previous value, and put itself), then the context could expand those two
> serializations.
>
> 2. For transaction operations, a context per transaction.
>
> @Sanne, would this be enough for you? In your [4] dev post you seem to
> want to go beyond marshalling into how we'd keep references of objects in
> memory, e.g. if a String is repeated in many places, have a way to
> centralise that storage in memory itself.
>
> Cheers,
>
> [4] http://lists.jboss.org/pipermail/infinispan-dev/2012-June/010925.html
> --
> Galder Zamarre?o
> Infinispan, Red Hat
>
> > On 21 Apr 2016, at 10:07, Galder Zamarre?o <galder at redhat.com> wrote:
> >
> > Hey guys,
> >
> > Just a quick heads up about [1].
> >
> > As I was looking at the marshalling code in core, I spotted the work
> done for [2] and by extension [3].
> >
> > I can certainly see the practicality of Will's solution in [2] which
> fitted quite well with the current marshalling architecture, but as we
> rethink the entire marshalling layer in [1], I'm wondering if a
> context-object where we can track repeated fields like Strings,
> Addresses... would be more suitable. For starters, we'd get rid of thread
> locals and could be more easily exposed in other places.
> >
> > Any ideas or updates you have on the topic please let me know.
> >
> > Cheers,
> >
> > [1] https://issues.jboss.org/browse/ISPN-6498
> > [2] https://issues.jboss.org/browse/ISPN-4979
> > [3] https://issues.jboss.org/browse/ISPN-2133
> > --
> > Galder Zamarre?o
> > Infinispan, 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/20160421/08e49989/attachment-0001.html 

From mudokonman at gmail.com  Thu Apr 21 09:18:59 2016
From: mudokonman at gmail.com (William Burns)
Date: Thu, 21 Apr 2016 13:18:59 +0000
Subject: [infinispan-dev] Potential for context object for
 serial/deserial in marshalling rework
In-Reply-To: <CAFm4XO01ZQ9Zqky72Sci2S1CHPYGjFUx80Evm-Pe2z-amYeYMA@mail.gmail.com>
References: <198F7FB4-BF9A-4EF6-9638-1531975F2EEA@redhat.com>
	<65F0A44E-DACC-470E-9DBE-F98F8652DF9E@redhat.com>
	<CAFm4XO01ZQ9Zqky72Sci2S1CHPYGjFUx80Evm-Pe2z-amYeYMA@mail.gmail.com>
Message-ID: <CA+YCuUN-0octh9v5=uYEEx7eCnAwaNA_MBHE+CK86RGn-tnGBw@mail.gmail.com>

On Thu, Apr 21, 2016 at 6:56 AM Sanne Grinovero <sanne at infinispan.org>
wrote:

> Hey Galder,
> these "scopes" you mention sound cool, but I'm afraid you'd end up
> designing a user friendly API more than allowing the level of
> performance optimisations we need.
>
> If we pass a "context" map, or eventually make it a map of maps when
> you'll figure you have nested structures such as [object type, object
> id], then:
>  - each deserialization event will need to perform multiple
> [concurrent]Map lookups
>

Unfortunately my implementation is quite similar although it is using a
HashMap and IdentityMap.  The main benefit of the externalizer I had was
that it only affected instances that extend it.


>  - I wouldn't be able to plug in an ad-hoc data structure: e.g. Will's
> "instance" strategy seems efficient :)
>  - we'll need to implement size-capping strategies, i.e. these would
> need to support eviction strategies, not least configuration options
> for such eviction.
>  - similar cost traversing multiple [concurrent]Map to write to the
> "context cache"
>
> I would suggest instead to give more flexibility to custom
> Externalizer implementors by making them stateful: if you could allow
> them to have something akin to the ComponentRegistry injected within
> the constructor, then a power user could pre-register custom services,
> look them up only once during construction, and then benefit from the
> performance of final field reads, from ad-hoc optimised containers.
> The implementor would also be fully responsible of making a reasonable
> choice to cap size.
>

To be honest I have been wanting this for a while.  Distributed Streams has
to do its own method of injecting the ComponentRegistry because we need
some cache components when using indexless querying.  Instead we have to do
[5] & [6] which is a bit cumbersome and is not usable by end users
whatsoever.

[5]
https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/stream/impl/intops/IntermediateOperation.java#L27
[6]
https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/stream/impl/LocalStreamManagerImpl.java#L251


>
> The complexity is then to make sure the components are booted in the
> right order, and that the Externalizer instance is bound to the right
> scope.
> I realize that the Externalizer chain needs to be booted early, but
> the services it would look up are unlikely to need anything else so it
> shouldn't be hard to figure a reasonable order for bootsrapping these
> components.
>
> For example, one complexity would be that an Externalizer instance
> which is bound to cache-specific services can not be part of an
> externalizer chain used for a different Cache, but I believe this is
> in place already because of the classloader requirements.
>
> WDYT, is this feasible? I realize it makes it harder to use, but then
> again I expect such tricks to be applied only by internal component
> and expert-level extensions (i.e. Hibernate OGM, Lucene, etc..).
>
> Thanks,
> Sanne
>
> On 21 April 2016 at 10:35, Galder Zamarre?o <galder at redhat.com> wrote:
> > For example, I'd like to get some clarification on the scope of the
> context object:
> >
> > @Will, will the solution you provided in [2] deal with multiple JGroups
> marshalling request callbacks? Or is it only designed for a single
> marshalling request callback coming from JGroups tgat contains a
> CacheStatusResponse map? Since it's a thread local is not easy to see
> what's the lifespan of these instances stored in the thread local...
> >
> > The simplest thing would be to have a new context created for each
> JGroups marshalling request.
> >
> > However, more optimizations could be achieved from:
> >
> > 1. For non-transaction operations, a context per operation. So if a
> cache.put() results in two operations being serialized (get to return
> previous value, and put itself), then the context could expand those two
> serializations.
> >
> > 2. For transaction operations, a context per transaction.
> >
> > @Sanne, would this be enough for you? In your [4] dev post you seem to
> want to go beyond marshalling into how we'd keep references of objects in
> memory, e.g. if a String is repeated in many places, have a way to
> centralise that storage in memory itself.
> >
> > Cheers,
> >
> > [4]
> http://lists.jboss.org/pipermail/infinispan-dev/2012-June/010925.html
> > --
> > Galder Zamarre?o
> > Infinispan, Red Hat
> >
> >> On 21 Apr 2016, at 10:07, Galder Zamarre?o <galder at redhat.com> wrote:
> >>
> >> Hey guys,
> >>
> >> Just a quick heads up about [1].
> >>
> >> As I was looking at the marshalling code in core, I spotted the work
> done for [2] and by extension [3].
> >>
> >> I can certainly see the practicality of Will's solution in [2] which
> fitted quite well with the current marshalling architecture, but as we
> rethink the entire marshalling layer in [1], I'm wondering if a
> context-object where we can track repeated fields like Strings,
> Addresses... would be more suitable. For starters, we'd get rid of thread
> locals and could be more easily exposed in other places.
> >>
> >> Any ideas or updates you have on the topic please let me know.
> >>
> >> Cheers,
> >>
> >> [1] https://issues.jboss.org/browse/ISPN-6498
> >> [2] https://issues.jboss.org/browse/ISPN-4979
> >> [3] https://issues.jboss.org/browse/ISPN-2133
> >> --
> >> Galder Zamarre?o
> >> Infinispan, 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160421/d7dd79ce/attachment.html 

From ttarrant at redhat.com  Thu Apr 21 10:02:44 2016
From: ttarrant at redhat.com (Tristan Tarrant)
Date: Thu, 21 Apr 2016 16:02:44 +0200
Subject: [infinispan-dev] Potential for context object for
 serial/deserial in marshalling rework
In-Reply-To: <57188CBA.8000302@redhat.com>
References: <198F7FB4-BF9A-4EF6-9638-1531975F2EEA@redhat.com>
	<57188CBA.8000302@redhat.com>
Message-ID: <5718DD84.4030307@redhat.com>

Turns out it's completely unrelated. But still needed :)

Tristan

On 21/04/2016 10:18, Tristan Tarrant wrote:
> On a related aspect,
>
> could this context object also hold security-related information ?
> Currently the "lightweight" security uses a ThreadLocal to avoid going
> through the AccessControlContext (which, is painfully slow), but I'd
> prefer a "context" approach.
>
> Tristan
>
> On 21/04/2016 10:07, Galder Zamarre?o wrote:
>> Hey guys,
>>
>> Just a quick heads up about [1].
>>
>> As I was looking at the marshalling code in core, I spotted the work done for [2] and by extension [3].
>>
>> I can certainly see the practicality of Will's solution in [2] which fitted quite well with the current marshalling architecture, but as we rethink the entire marshalling layer in [1], I'm wondering if a context-object where we can track repeated fields like Strings, Addresses... would be more suitable. For starters, we'd get rid of thread locals and could be more easily exposed in other places.
>>
>> Any ideas or updates you have on the topic please let me know.
>>
>> Cheers,
>>
>> [1] https://issues.jboss.org/browse/ISPN-6498
>> [2] https://issues.jboss.org/browse/ISPN-4979
>> [3] https://issues.jboss.org/browse/ISPN-2133
>> --
>> Galder Zamarre?o
>> Infinispan, Red Hat
>>
>>
>> _______________________________________________
>> 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 galder at redhat.com  Thu Apr 21 11:08:14 2016
From: galder at redhat.com (=?windows-1252?Q?Galder_Zamarre=F1o?=)
Date: Thu, 21 Apr 2016 17:08:14 +0200
Subject: [infinispan-dev] Remote execute null return (ISPN-6406)
In-Reply-To: <5717FA6D.7060302@redhat.com>
References: <2F1C43D9-BB1F-4E5D-98B8-36208AFE5DF7@redhat.com>
	<CAA9R9O7b_L-fZ_rnA191HC_tXijMT5OnVh9XQX=8r3h6pm+f9g@mail.gmail.com>
	<5717FA6D.7060302@redhat.com>
Message-ID: <DB697F08-1333-42BD-A6FB-D715726DB753@redhat.com>

Thanks guys for the feedback.

We already implictly support null in some of the commands, e.g. get returns a particular status code when the key is not found. 

Exec should have something like that eventually but for now the best would be to send back an empty byte[] when null is returned. That's better than what we do right now and as Sebastian rightly said, it should be not much different for the users.

Cheers,
--
Galder Zamarre?o
Infinispan, Red Hat

> On 20 Apr 2016, at 23:53, Dennis Reed <dereed at redhat.com> wrote:
> 
> A related question -- do you want to support null in the protocol?  Not
> all languages even have a concept of null.
> 
> So you do need to make a decision whether to support null to the
> exclusion of languages that don't have it (or make Hot Rod more
> complicated to use in those languages), or disallow null to increase
> interoperability but with a restriction of functionality in those
> languages that do allow it.
> 
> -Dennis
> 
> 
> On 04/20/2016 08:00 AM, Sebastian Laskawiec wrote:
>> I think this is pretty common problem [3]. 
>> 
>> On the other hand most of the users won't be interested in
>> distinguishing nulls from empty strings (at least in my opinion). So how
>> about leaving it as is by default and creating some configuration
>> parameter for using new status code as you suggested (just in case
>> someone would have to distinguish those two).
>> 
>> This way we would be somewhat backwards compatible and we would have a
>> rescue option for some users who would need this feature.
>> 
>> [3] http://blog.bdoughan.com/2012/04/binding-to-json-xml-handling-null.html
>> 
>> On Tue, Apr 19, 2016 at 6:31 PM, Galder Zamarre?o <galder at redhat.com
>> <mailto:galder at redhat.com>> wrote:
>> 
>>    Hi all,
>> 
>>    A Hot Rod protocol change might be required as a result of [1].
>> 
>>    In essence, the Hot Rod protocol does not specify how remote exec
>>    calls that return null should respond back to the client [2].
>> 
>>    Returning an empty byte[] won't cut it since returning an empty
>>    String would be represented that way, and that's different to null.
>> 
>>    I don't know how this could be handled without modifying the
>>    protocol, any ideas?
>> 
>>    If modifying the protocol, adding a new status code would be a way
>>    to handle it.
>> 
>>    Thoughts?
>> 
>>    [1] https://issues.jboss.org/browse/ISPN-6406
>>    [2]
>>    http://infinispan.org/docs/8.2.x/user_guide/user_guide.html#_hot_rod_protocol_2_0
>>    --
>>    Galder Zamarre?o
>>    Infinispan, 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
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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 rvansa at redhat.com  Fri Apr 22 08:11:20 2016
From: rvansa at redhat.com (Radim Vansa)
Date: Fri, 22 Apr 2016 14:11:20 +0200
Subject: [infinispan-dev] Scattered cache
Message-ID: <571A14E8.6080504@redhat.com>

Hi everyone,

in Konstanz I've briefly mentioned alternative distributed 2-owners 
cache design, now with working title 'Scattered cache'. I've elaborated 
on this topic on wiki [1] and I would welcome your thoughts about that.

Eventually I'd like to do a performance POC (operations without ST 
implementation).

Radim

[1] https://github.com/infinispan/infinispan/wiki/Scattered-Cache-design-doc

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


From bban at redhat.com  Mon Apr 25 03:24:23 2016
From: bban at redhat.com (Bela Ban)
Date: Mon, 25 Apr 2016 09:24:23 +0200
Subject: [infinispan-dev] Scattered cache
In-Reply-To: <571A14E8.6080504@redhat.com>
References: <571A14E8.6080504@redhat.com>
Message-ID: <571DC627.2050207@redhat.com>

FYI: I've also added a link to the agenda of our next Konstanz meeting

On 22/04/16 14:11, Radim Vansa wrote:
> Hi everyone,
>
> in Konstanz I've briefly mentioned alternative distributed 2-owners
> cache design, now with working title 'Scattered cache'. I've elaborated
> on this topic on wiki [1] and I would welcome your thoughts about that.
>
> Eventually I'd like to do a performance POC (operations without ST
> implementation).
>
> Radim
>
> [1] https://github.com/infinispan/infinispan/wiki/Scattered-Cache-design-doc
>

-- 
Bela Ban, JGroups lead (http://www.jgroups.org)


From galder at redhat.com  Mon Apr 25 05:59:04 2016
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Mon, 25 Apr 2016 11:59:04 +0200
Subject: [infinispan-dev] Go hotrod client for Infinispan
In-Reply-To: <CAAis47XHEBi=1UW=ma7ELEBGpfVqOGqqZMz-Ofuq7s7cDah_1g@mail.gmail.com>
References: <CAAis47XHEBi=1UW=ma7ELEBGpfVqOGqqZMz-Ofuq7s7cDah_1g@mail.gmail.com>
Message-ID: <14AB3A6E-52B9-451A-89B6-55E9205D5C63@redhat.com>

Thanks for the contribution Ugo, great work bringing the Go community closer :)

Cheers,
--
Galder Zamarre?o
Infinispan, Red Hat

> On 12 Apr 2016, at 11:04, ugol <ugo.landini at gmail.com> wrote:
> 
> Hi guys,
> I have implemented just get and posts operations at the moment but
> hopefully with all bells & whistles:
> 
> - 2.5 protocol
> - lifespan & expiration as optional parameters with multiple time units
> - named caches
> - previous values options
> - error handling
> - "full" test suite
> 
> https://github.com/ugol/infinispan-go/
> 
> if you don't see anything blatantly wrong, I can easily complete all
> L1 hotrod operations, write a bit of documentation and then start the
> implementation of L2/L3
> 
> if you want to test it, just run an 8.2 server and a "go test -v".
> Sometimes you can see an error due to a race condition in the tests
> for the message ids, didn't have the time to fix it
> 
> ciao
> -- 
> uL
> 
> Pragmatist
> http://blog.ugolandini.com
> http://www.flickr.com/photos/ugol/
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev



From ugo.landini at gmail.com  Mon Apr 25 06:13:43 2016
From: ugo.landini at gmail.com (ugol)
Date: Mon, 25 Apr 2016 12:13:43 +0200
Subject: [infinispan-dev] Go hotrod client for Infinispan
In-Reply-To: <14AB3A6E-52B9-451A-89B6-55E9205D5C63@redhat.com>
References: <CAAis47XHEBi=1UW=ma7ELEBGpfVqOGqqZMz-Ofuq7s7cDah_1g@mail.gmail.com>
	<14AB3A6E-52B9-451A-89B6-55E9205D5C63@redhat.com>
Message-ID: <CAAis47XtQ9CCs124Ku0S0ynphyCUMyY7xjnnLse+kBfLkTSV7w@mail.gmail.com>

Hey Galder,
Didn't have much free time latest weeks, but I'll try to finish the
other L1 operations this week.

On Mon, Apr 25, 2016 at 11:59 AM, Galder Zamarre?o <galder at redhat.com> wrote:
> Thanks for the contribution Ugo, great work bringing the Go community closer :)
>
> Cheers,
> --
> Galder Zamarre?o
> Infinispan, Red Hat
>
>> On 12 Apr 2016, at 11:04, ugol <ugo.landini at gmail.com> wrote:
>>
>> Hi guys,
>> I have implemented just get and posts operations at the moment but
>> hopefully with all bells & whistles:
>>
>> - 2.5 protocol
>> - lifespan & expiration as optional parameters with multiple time units
>> - named caches
>> - previous values options
>> - error handling
>> - "full" test suite
>>
>> https://github.com/ugol/infinispan-go/
>>
>> if you don't see anything blatantly wrong, I can easily complete all
>> L1 hotrod operations, write a bit of documentation and then start the
>> implementation of L2/L3
>>
>> if you want to test it, just run an 8.2 server and a "go test -v".
>> Sometimes you can see an error due to a race condition in the tests
>> for the message ids, didn't have the time to fix it
>>
>> ciao
>> --
>> uL
>>
>> Pragmatist
>> http://blog.ugolandini.com
>> http://www.flickr.com/photos/ugol/
>> _______________________________________________
>> 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



-- 
uL

Pragmatist
http://blog.ugolandini.com
http://www.flickr.com/photos/ugol/


From slaskawi at redhat.com  Mon Apr 25 06:43:33 2016
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Mon, 25 Apr 2016 12:43:33 +0200
Subject: [infinispan-dev] Interesting reading - String compaction in JDK9
Message-ID: <CAA9R9O6y6_DOaiXXbsWqgcqui=CrJpzDQKBwHcWp4vuAG8L+9w@mail.gmail.com>

I stumbled upon this [1] when reviewing [2].

Have a nice reading!
Sebastian

[1] http://www.javaspecialists.eu/archive/Issue237.html
[2] https://github.com/infinispan/infinispan/pull/4233
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160425/6ee49ae8/attachment.html 

From slaskawi at redhat.com  Mon Apr 25 08:30:55 2016
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Mon, 25 Apr 2016 14:30:55 +0200
Subject: [infinispan-dev] Status 2016/04/25
Message-ID: <CAA9R9O5eapZSnci6gAbCvd=Sj1wLqoj-mDjeRLnE20dDbDd18w@mail.gmail.com>

Hey!

Unfortunately I won't be able to make it for today's IRC meeting (if there
will be one), so here is my status:

   - ISPN-5721 SNI implementation is done (2 PRs sent [1][2]). Both PRs are
   waiting for review.
   - I'm planning to write some blog post as soon as they are merged.
   - This week I'll concentrate on setting up Openshift environment on my
   local laptop and investigating the best way to implement:
      - a Hotrod server image.
         - At the moment the best way is to create a new example and ask
         Openshift team to put it under their Github organization [3].
This way it
         will be tested by their testsuite (!!!).
         - Cloud Enablement team also plans to do some work with this area
         but I couldn't get any meaningful information.
         - The first iteration of the image might be really quick and dirty
         (just to start moving forward with other things)
      - investigating Config Map [4] and how this might help with Hotrod
      server configuration.
      - accessing the data from different pods (Hotrod cluster is in Pod A
      and clients are in Pod B)
      - think a little bit about multi tenancy (a quick and dirty solution
      would be to prefix caches with cache containers but maybe there
is a better
      way)
   - Plus, as usual, some small bug fixes, CI maintenance and product
   related work.

That's all from me.

Thanks!
Sebastian

[1] https://github.com/infinispan/infinispan/pull/4262
[2] https://github.com/infinispan/infinispan/pull/4255
[3] https://github.com/search?q=org%3Aopenshift+-ex
[4] https://docs.openshift.org/latest/dev_guide/configmaps.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160425/7152f4ce/attachment.html 

From rvansa at redhat.com  Mon Apr 25 08:36:15 2016
From: rvansa at redhat.com (Radim Vansa)
Date: Mon, 25 Apr 2016 14:36:15 +0200
Subject: [infinispan-dev] Marshalling/unmarshalling known type
Message-ID: <571E0F3F.9000801@redhat.com>

Hi,

I've noticed that sometimes we marshall objects just using 
output.writeObject() even though we know the target type - one example 
for all is CommandInvocationId. That's somewhat suboptimal, as we know 
that there won't be any CommandInvocationIdEx, so we could spare the 
externalizer lookup and few bytes for object identifier.

Is there any better way than

new CommandInvocationId.Externalizer().writeObject(output, 
commandInvocationId)?

Should we use this ^? I guess that object allocation will be eliminated 
here easily.

Radim

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


From pedro at infinispan.org  Mon Apr 25 09:25:18 2016
From: pedro at infinispan.org (Pedro Ruivo)
Date: Mon, 25 Apr 2016 14:25:18 +0100
Subject: [infinispan-dev] Marshalling/unmarshalling known type
In-Reply-To: <571E0F3F.9000801@redhat.com>
References: <571E0F3F.9000801@redhat.com>
Message-ID: <571E1ABE.3030503@infinispan.org>

Hi,

I've noticed the same when I refactor the commands marshalling.

I thought about creating a MarshallUtil.writeObjectWithExternalizer(T 
obj, Externalizer<T> ext) to handle this cases but it was outside the 
scope of that JIRA.

In the end, most of the externalizers are stateless and it can be a 
Singleton and the allocation can be removed. +1 to create a JIRA to 
improve this cases.

Pedro


On 04/25/2016 01:36 PM, Radim Vansa wrote:
> Hi,
>
> I've noticed that sometimes we marshall objects just using
> output.writeObject() even though we know the target type - one example
> for all is CommandInvocationId. That's somewhat suboptimal, as we know
> that there won't be any CommandInvocationIdEx, so we could spare the
> externalizer lookup and few bytes for object identifier.
>
> Is there any better way than
>
> new CommandInvocationId.Externalizer().writeObject(output,
> commandInvocationId)?
>
> Should we use this ^? I guess that object allocation will be eliminated
> here easily.
>
> Radim
>

From sanne at infinispan.org  Mon Apr 25 09:34:33 2016
From: sanne at infinispan.org (Sanne Grinovero)
Date: Mon, 25 Apr 2016 15:34:33 +0200
Subject: [infinispan-dev] Marshalling/unmarshalling known type
In-Reply-To: <571E1ABE.3030503@infinispan.org>
References: <571E0F3F.9000801@redhat.com> <571E1ABE.3030503@infinispan.org>
Message-ID: <CAFm4XO1gtG2dudYup9=E6TzzOXGYZ4Q+x1XSfONpSeD_dgyO8w@mail.gmail.com>

+1

I do similar tricks in externalizing some metadata for Lucene: some
custom Externalizers expose a static helper method so others from the
same package can invoke it directly.

On 25 April 2016 at 15:25, Pedro Ruivo <pedro at infinispan.org> wrote:
> Hi,
>
> I've noticed the same when I refactor the commands marshalling.
>
> I thought about creating a MarshallUtil.writeObjectWithExternalizer(T
> obj, Externalizer<T> ext) to handle this cases but it was outside the
> scope of that JIRA.
>
> In the end, most of the externalizers are stateless and it can be a
> Singleton and the allocation can be removed. +1 to create a JIRA to
> improve this cases.
>
> Pedro
>
>
> On 04/25/2016 01:36 PM, Radim Vansa wrote:
>> Hi,
>>
>> I've noticed that sometimes we marshall objects just using
>> output.writeObject() even though we know the target type - one example
>> for all is CommandInvocationId. That's somewhat suboptimal, as we know
>> that there won't be any CommandInvocationIdEx, so we could spare the
>> externalizer lookup and few bytes for object identifier.
>>
>> Is there any better way than
>>
>> new CommandInvocationId.Externalizer().writeObject(output,
>> commandInvocationId)?
>>
>> Should we use this ^? I guess that object allocation will be eliminated
>> here easily.
>>
>> Radim
>>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

From gustavo at infinispan.org  Mon Apr 25 10:35:57 2016
From: gustavo at infinispan.org (Gustavo Fernandes)
Date: Mon, 25 Apr 2016 15:35:57 +0100
Subject: [infinispan-dev] Weekly IRC meeting minutes 2016-04-25
Message-ID: <CAH8Ud1EX2wAiL=wa+yyqJA+KV8FJXtRNfN0KBF1MsOOSqw6=Kw@mail.gmail.com>

Please find the logs here:

http://transcripts.jboss.org/meeting/irc.freenode.org/infinispan/2016/infinispan.2016-04-25-14.06.html

Thanks,
Gustavo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160425/1a90a902/attachment-0001.html 

From galder at redhat.com  Mon Apr 25 10:39:51 2016
From: galder at redhat.com (=?utf-8?Q?Galder_Zamarre=C3=B1o?=)
Date: Mon, 25 Apr 2016 16:39:51 +0200
Subject: [infinispan-dev] Release 9.0.0.Alpha1 is out!
In-Reply-To: <1561955191.9745005.1460537119617.JavaMail.zimbra@redhat.com>
References: <1561955191.9745005.1460537119617.JavaMail.zimbra@redhat.com>
Message-ID: <042285D4-8FAC-4DF7-92D7-24BA3C94E023@redhat.com>

Congratulations on your first release :D

--
Galder Zamarre?o
Infinispan, Red Hat

> On 13 Apr 2016, at 10:45, Vittorio Rigamonti <vrigamon at redhat.com> wrote:
> 
> Hi Infinispan Devs,
> 
> I'm pleased to announce that the first release of the 9 serie is out.
> 
> http://blog.infinispan.org/2016/04/infinispan-900alpha1-is-out.html
> 
> It's an Alpha so enjoy it.
> 
> Cheers,
> Vittorio
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev



From rory.odonnell at oracle.com  Fri Apr 29 09:18:18 2016
From: rory.odonnell at oracle.com (Rory O'Donnell)
Date: Fri, 29 Apr 2016 14:18:18 +0100
Subject: [infinispan-dev] Early Access builds of JDK 9 b116 & JDK 9 with
 Project Jigsaw b115 (#4909) are available on java.net
Message-ID: <57235F1A.5080200@oracle.com>


Hi Galder,

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

Early Access b115 <https://jdk9.java.net/jigsaw/> (#4909) for JDK 9 with 
Project Jigsaw is available on java.net.

Recent changes:

  * in b114
      o Replace
        ?com.apple.eawt
        ?com.apple.eio
        With platform independent alternatives in java.awt
  * in b115
      o As per JEP 260, all non-Critical types/members should be moved
        out of
        sun/reflect and placed into a non-exported package. Only
        critical APIs
        should remain in sun.reflect.

We are very interested in hearing your experiences in testing any Early 
Access builds. Have you have begun testing against
JDK 9 and or JDK 9 with Project Jigsaw EA builds, have you uncovered 
showstopper issues that you would like to discuss?
We would really like to hear your findings so far, either reply to me or 
via the mailing lists [1], [2].

Rgds,Rory

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/
[2] http://mail.openjdk.java.net/pipermail/jdk9-dev/

-- 
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/20160429/9ab6394d/attachment.html 

From slaskawi at redhat.com  Fri Apr 29 11:29:41 2016
From: slaskawi at redhat.com (Sebastian Laskawiec)
Date: Fri, 29 Apr 2016 17:29:41 +0200
Subject: [infinispan-dev] Multi tenancy support for Infinispan
Message-ID: <CAA9R9O5zC+=ugojy4v6-GKUH4vH+-WwXT-iCHbZuKKL+hFojsA@mail.gmail.com>

Dear Community,

Please have a look at the design of Multi tenancy support for Infinispan
[1]. I would be more than happy to get some feedback from you.

Highlights:

   - The implementation will be based on a Router (which will be built
   based on Netty)
   - Multiple Hot Rod and REST servers will be attached to the router which
   in turn will be attached to the endpoint
   - The router will operate on a binary protocol when using Hot Rod
   clients and path-based routing when using REST
   - Memcached will be out of scope
   - The router will support SSL+SNI

Thanks
Sebastian

[1]
https://github.com/infinispan/infinispan/wiki/Multi-tenancy-for-Hotrod-Server
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160429/9761e7af/attachment.html