[infinispan-dev] Calling getCache with a template and defined configuration

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[infinispan-dev] Calling getCache with a template and defined configuration

William Burns-3
When working on another project using Infinispan the code being used was a bit interesting and I don't think our template configuration handling was expecting it do so in such a way.

Essentially the code defined a template for a distributed cache as well as some named caches.  Then whenever a cache is retrieved it would pass the given name and always the distributed cache template.  Unfortunately with the way templates work they essentially redefine a cache first so the actual cache configuration was wiped out.  In this example I was able to get the code to change to using a default cache instead, which is the behavior that is needed.

The issue though at hand is whether we should allow a user to call getCache in such a way. My initial thought is to have it throw some sort of configuration exception when this is invoked. But there are some possible options.

1. Throw a configuration exception not allowing a user to use a template with an already defined cache. This has a slight disconnect between configuration and runtime, since if a user adds a new definition it could cause runtime issues.
2. Log an error/warning message when this occurs. Is this enough though? Still could have runtime issues that are possibly undetected.
3. Merge the configurations together applying the template first.  This would be akin to how default cache works currently, but you would get to define your default template configuration at runtime. This sounded like the best option to me, but the problem is what if someone calls getCache using the same cache name but a different template. This could get hairy as well.

Really thinking about the future, disconnecting the cache definition and retrieval would be the best option, but we can't do that this late in the game.

What do you guys think?

 - Will

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Calling getCache with a template and defined configuration

Radim Vansa
While we could define the behaviour as in 3), I think that this is most
likely a configuration error. Therefore, I'd go with 1), and ideally
provide a link to FAQ/docs where you'd explain what exactly happened in
the exception message.

R.

On 02/27/2017 03:31 PM, William Burns wrote:

> When working on another project using Infinispan the code being used
> was a bit interesting and I don't think our template configuration
> handling was expecting it do so in such a way.
>
> Essentially the code defined a template for a distributed cache as
> well as some named caches. Then whenever a cache is retrieved it would
> pass the given name and always the distributed cache template.  
> Unfortunately with the way templates work they essentially redefine a
> cache first so the actual cache configuration was wiped out.  In this
> example I was able to get the code to change to using a default cache
> instead, which is the behavior that is needed.
>
> The issue though at hand is whether we should allow a user to call
> getCache in such a way. My initial thought is to have it throw some
> sort of configuration exception when this is invoked. But there are
> some possible options.
>
> 1. Throw a configuration exception not allowing a user to use a
> template with an already defined cache. This has a slight disconnect
> between configuration and runtime, since if a user adds a new
> definition it could cause runtime issues.
> 2. Log an error/warning message when this occurs. Is this enough
> though? Still could have runtime issues that are possibly undetected.
> 3. Merge the configurations together applying the template first.  
> This would be akin to how default cache works currently, but you would
> get to define your default template configuration at runtime. This
> sounded like the best option to me, but the problem is what if someone
> calls getCache using the same cache name but a different template.
> This could get hairy as well.
>
> Really thinking about the future, disconnecting the cache definition
> and retrieval would be the best option, but we can't do that this late
> in the game.
>
> What do you guys think?
>
>  - Will
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Calling getCache with a template and defined configuration

Dan Berindei
In reply to this post by William Burns-3
I would go for option 2.

We already started disconnecting the cache definition and retrieval,
at least `getCache(name)` doesn't define a new cache based on the
default configuration any more. So I don't think it would be too much,
even at this point, to deprecate all the overloads of `getCache` that
can define a new cache and advise users to use `defineConfiguration`
instead.



Cheers
Dan


On Mon, Feb 27, 2017 at 4:31 PM, William Burns <[hidden email]> wrote:

> When working on another project using Infinispan the code being used was a
> bit interesting and I don't think our template configuration handling was
> expecting it do so in such a way.
>
> Essentially the code defined a template for a distributed cache as well as
> some named caches.  Then whenever a cache is retrieved it would pass the
> given name and always the distributed cache template.  Unfortunately with
> the way templates work they essentially redefine a cache first so the actual
> cache configuration was wiped out.  In this example I was able to get the
> code to change to using a default cache instead, which is the behavior that
> is needed.
>
> The issue though at hand is whether we should allow a user to call getCache
> in such a way. My initial thought is to have it throw some sort of
> configuration exception when this is invoked. But there are some possible
> options.
>
> 1. Throw a configuration exception not allowing a user to use a template
> with an already defined cache. This has a slight disconnect between
> configuration and runtime, since if a user adds a new definition it could
> cause runtime issues.
> 2. Log an error/warning message when this occurs. Is this enough though?
> Still could have runtime issues that are possibly undetected.
> 3. Merge the configurations together applying the template first.  This
> would be akin to how default cache works currently, but you would get to
> define your default template configuration at runtime. This sounded like the
> best option to me, but the problem is what if someone calls getCache using
> the same cache name but a different template. This could get hairy as well.
>
> Really thinking about the future, disconnecting the cache definition and
> retrieval would be the best option, but we can't do that this late in the
> game.
>
> What do you guys think?
>
>  - Will
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Calling getCache with a template and defined configuration

Dan Berindei
I forgot to mention users can define their caches with
<distributed-cache configuration="template">...</distributed-cache> if
they want inheritance. So we don't need a way to merge configurations
at this level.


On Mon, Feb 27, 2017 at 4:52 PM, Dan Berindei <[hidden email]> wrote:

> I would go for option 2.
>
> We already started disconnecting the cache definition and retrieval,
> at least `getCache(name)` doesn't define a new cache based on the
> default configuration any more. So I don't think it would be too much,
> even at this point, to deprecate all the overloads of `getCache` that
> can define a new cache and advise users to use `defineConfiguration`
> instead.
>
>
>
> Cheers
> Dan
>
>
> On Mon, Feb 27, 2017 at 4:31 PM, William Burns <[hidden email]> wrote:
>> When working on another project using Infinispan the code being used was a
>> bit interesting and I don't think our template configuration handling was
>> expecting it do so in such a way.
>>
>> Essentially the code defined a template for a distributed cache as well as
>> some named caches.  Then whenever a cache is retrieved it would pass the
>> given name and always the distributed cache template.  Unfortunately with
>> the way templates work they essentially redefine a cache first so the actual
>> cache configuration was wiped out.  In this example I was able to get the
>> code to change to using a default cache instead, which is the behavior that
>> is needed.
>>
>> The issue though at hand is whether we should allow a user to call getCache
>> in such a way. My initial thought is to have it throw some sort of
>> configuration exception when this is invoked. But there are some possible
>> options.
>>
>> 1. Throw a configuration exception not allowing a user to use a template
>> with an already defined cache. This has a slight disconnect between
>> configuration and runtime, since if a user adds a new definition it could
>> cause runtime issues.
>> 2. Log an error/warning message when this occurs. Is this enough though?
>> Still could have runtime issues that are possibly undetected.
>> 3. Merge the configurations together applying the template first.  This
>> would be akin to how default cache works currently, but you would get to
>> define your default template configuration at runtime. This sounded like the
>> best option to me, but the problem is what if someone calls getCache using
>> the same cache name but a different template. This could get hairy as well.
>>
>> Really thinking about the future, disconnecting the cache definition and
>> retrieval would be the best option, but we can't do that this late in the
>> game.
>>
>> What do you guys think?
>>
>>  - Will
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Calling getCache with a template and defined configuration

William Burns-3
In reply to this post by Radim Vansa


On Mon, Feb 27, 2017 at 9:50 AM Radim Vansa <[hidden email]> wrote:
While we could define the behaviour as in 3), I think that this is most

Yeah rereading what I wrote again, it was definitely misleading. 3) was what I wanted when I first found the issue.
 
likely a configuration error. Therefore, I'd go with 1), and ideally

That is what I was leaning towards as well.
 
provide a link to FAQ/docs where you'd explain what exactly happened in
the exception message.

Yeah I will make sure we have some stuff added to the template section of the user guide.
 

R.

On 02/27/2017 03:31 PM, William Burns wrote:
> When working on another project using Infinispan the code being used
> was a bit interesting and I don't think our template configuration
> handling was expecting it do so in such a way.
>
> Essentially the code defined a template for a distributed cache as
> well as some named caches. Then whenever a cache is retrieved it would
> pass the given name and always the distributed cache template.
> Unfortunately with the way templates work they essentially redefine a
> cache first so the actual cache configuration was wiped out.  In this
> example I was able to get the code to change to using a default cache
> instead, which is the behavior that is needed.
>
> The issue though at hand is whether we should allow a user to call
> getCache in such a way. My initial thought is to have it throw some
> sort of configuration exception when this is invoked. But there are
> some possible options.
>
> 1. Throw a configuration exception not allowing a user to use a
> template with an already defined cache. This has a slight disconnect
> between configuration and runtime, since if a user adds a new
> definition it could cause runtime issues.
> 2. Log an error/warning message when this occurs. Is this enough
> though? Still could have runtime issues that are possibly undetected.
> 3. Merge the configurations together applying the template first.
> This would be akin to how default cache works currently, but you would
> get to define your default template configuration at runtime. This
> sounded like the best option to me, but the problem is what if someone
> calls getCache using the same cache name but a different template.
> This could get hairy as well.
>
> Really thinking about the future, disconnecting the cache definition
> and retrieval would be the best option, but we can't do that this late
> in the game.
>
> What do you guys think?
>
>  - Will
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Calling getCache with a template and defined configuration

William Burns-3
In reply to this post by Dan Berindei


On Mon, Feb 27, 2017 at 9:55 AM Dan Berindei <[hidden email]> wrote:
I would go for option 2.

Do you think a WARN message will be enough? I am a bit weary about this option myself.
 

We already started disconnecting the cache definition and retrieval,
at least `getCache(name)` doesn't define a new cache based on the
default configuration any more. So I don't think it would be too much,
even at this point, to deprecate all the overloads of `getCache` that
can define a new cache and advise users to use `defineConfiguration`
instead.

Hrmm I like the idea of deprecating the overloads :)
 



Cheers
Dan


On Mon, Feb 27, 2017 at 4:31 PM, William Burns <[hidden email]> wrote:
> When working on another project using Infinispan the code being used was a
> bit interesting and I don't think our template configuration handling was
> expecting it do so in such a way.
>
> Essentially the code defined a template for a distributed cache as well as
> some named caches.  Then whenever a cache is retrieved it would pass the
> given name and always the distributed cache template.  Unfortunately with
> the way templates work they essentially redefine a cache first so the actual
> cache configuration was wiped out.  In this example I was able to get the
> code to change to using a default cache instead, which is the behavior that
> is needed.
>
> The issue though at hand is whether we should allow a user to call getCache
> in such a way. My initial thought is to have it throw some sort of
> configuration exception when this is invoked. But there are some possible
> options.
>
> 1. Throw a configuration exception not allowing a user to use a template
> with an already defined cache. This has a slight disconnect between
> configuration and runtime, since if a user adds a new definition it could
> cause runtime issues.
> 2. Log an error/warning message when this occurs. Is this enough though?
> Still could have runtime issues that are possibly undetected.
> 3. Merge the configurations together applying the template first.  This
> would be akin to how default cache works currently, but you would get to
> define your default template configuration at runtime. This sounded like the
> best option to me, but the problem is what if someone calls getCache using
> the same cache name but a different template. This could get hairy as well.
>
> Really thinking about the future, disconnecting the cache definition and
> retrieval would be the best option, but we can't do that this late in the
> game.
>
> What do you guys think?
>
>  - Will
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Calling getCache with a template and defined configuration

William Burns-3
So while I was trying to work on this, I have to admit I am even more torn in regards to what to do.  Looking at [1]  it looks like the template should only be applied if the cache configuration is not currently defined.  Unfortunately it doesn't work this way and always applies this template to any existing configuration. So I am thinking an alternative is to instead make it work as the documentation states, only using the template if the cache is not currently defined.  This seems more logical to me at least.

With that change the getCache(String, String) could stay as long as it is documented that a template is only applied if no cache configuration exists.

What do you guys think?

[1] https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/manager/EmbeddedCacheManager.java#L84

On Mon, Feb 27, 2017 at 10:09 AM William Burns <[hidden email]> wrote:
On Mon, Feb 27, 2017 at 9:55 AM Dan Berindei <[hidden email]> wrote:
I would go for option 2.

Do you think a WARN message will be enough? I am a bit weary about this option myself.
 

We already started disconnecting the cache definition and retrieval,
at least `getCache(name)` doesn't define a new cache based on the
default configuration any more. So I don't think it would be too much,
even at this point, to deprecate all the overloads of `getCache` that
can define a new cache and advise users to use `defineConfiguration`
instead.

Hrmm I like the idea of deprecating the overloads :)
 



Cheers
Dan


On Mon, Feb 27, 2017 at 4:31 PM, William Burns <[hidden email]> wrote:
> When working on another project using Infinispan the code being used was a
> bit interesting and I don't think our template configuration handling was
> expecting it do so in such a way.
>
> Essentially the code defined a template for a distributed cache as well as
> some named caches.  Then whenever a cache is retrieved it would pass the
> given name and always the distributed cache template.  Unfortunately with
> the way templates work they essentially redefine a cache first so the actual
> cache configuration was wiped out.  In this example I was able to get the
> code to change to using a default cache instead, which is the behavior that
> is needed.
>
> The issue though at hand is whether we should allow a user to call getCache
> in such a way. My initial thought is to have it throw some sort of
> configuration exception when this is invoked. But there are some possible
> options.
>
> 1. Throw a configuration exception not allowing a user to use a template
> with an already defined cache. This has a slight disconnect between
> configuration and runtime, since if a user adds a new definition it could
> cause runtime issues.
> 2. Log an error/warning message when this occurs. Is this enough though?
> Still could have runtime issues that are possibly undetected.
> 3. Merge the configurations together applying the template first.  This
> would be akin to how default cache works currently, but you would get to
> define your default template configuration at runtime. This sounded like the
> best option to me, but the problem is what if someone calls getCache using
> the same cache name but a different template. This could get hairy as well.
>
> Really thinking about the future, disconnecting the cache definition and
> retrieval would be the best option, but we can't do that this late in the
> game.
>
> What do you guys think?
>
>  - Will
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Calling getCache with a template and defined configuration

Radim Vansa
I still think that if the cache is already defined, defineConfiguration
should throw an exception. This javadoc was written 7 years ago [1],
maybe with a different intention.
Strange and complex combinations don't help. We have made a clear
separation between templates and cache configurations; you should not
use regular cache configuration as a template for programmatically
defined cache anymore, and if you really want to, there are means to
that (load, undefine, define).

Btw., the javadoc is out of date, too, since it mentions default cache
which has been removed recently.

R.

[1]
https://github.com/infinispan/infinispan/commit/73d99d37ebfb8af6b64df6a7579a2448deacbde7#diff-e2b618b97769a45ec42eb5910a8c2119R62

On 02/28/2017 10:51 PM, William Burns wrote:

> So while I was trying to work on this, I have to admit I am even more
> torn in regards to what to do.  Looking at [1] it looks like the
> template should only be applied if the cache configuration is not
> currently defined.  Unfortunately it doesn't work this way and always
> applies this template to any existing configuration. So I am thinking
> an alternative is to instead make it work as the documentation states,
> only using the template if the cache is not currently defined. This
> seems more logical to me at least.
>
> With that change the getCache(String, String) could stay as long as it
> is documented that a template is only applied if no cache
> configuration exists.
>
> What do you guys think?
>
> [1]
> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/manager/EmbeddedCacheManager.java#L84 
>
>
> On Mon, Feb 27, 2017 at 10:09 AM William Burns <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On Mon, Feb 27, 2017 at 9:55 AM Dan Berindei
>     <[hidden email] <mailto:[hidden email]>> wrote:
>
>         I would go for option 2.
>
>
>     Do you think a WARN message will be enough? I am a bit weary about
>     this option myself.
>
>
>         We already started disconnecting the cache definition and
>         retrieval,
>         at least `getCache(name)` doesn't define a new cache based on the
>         default configuration any more. So I don't think it would be
>         too much,
>         even at this point, to deprecate all the overloads of
>         `getCache` that
>         can define a new cache and advise users to use
>         `defineConfiguration`
>         instead.
>
>
>     Hrmm I like the idea of deprecating the overloads :)
>
>
>
>
>         Cheers
>         Dan
>
>
>         On Mon, Feb 27, 2017 at 4:31 PM, William Burns
>         <[hidden email] <mailto:[hidden email]>> wrote:
>         > When working on another project using Infinispan the code
>         being used was a
>         > bit interesting and I don't think our template configuration
>         handling was
>         > expecting it do so in such a way.
>         >
>         > Essentially the code defined a template for a distributed
>         cache as well as
>         > some named caches.  Then whenever a cache is retrieved it
>         would pass the
>         > given name and always the distributed cache template.
>         Unfortunately with
>         > the way templates work they essentially redefine a cache
>         first so the actual
>         > cache configuration was wiped out.  In this example I was
>         able to get the
>         > code to change to using a default cache instead, which is
>         the behavior that
>         > is needed.
>         >
>         > The issue though at hand is whether we should allow a user
>         to call getCache
>         > in such a way. My initial thought is to have it throw some
>         sort of
>         > configuration exception when this is invoked. But there are
>         some possible
>         > options.
>         >
>         > 1. Throw a configuration exception not allowing a user to
>         use a template
>         > with an already defined cache. This has a slight disconnect
>         between
>         > configuration and runtime, since if a user adds a new
>         definition it could
>         > cause runtime issues.
>         > 2. Log an error/warning message when this occurs. Is this
>         enough though?
>         > Still could have runtime issues that are possibly undetected.
>         > 3. Merge the configurations together applying the template
>         first.  This
>         > would be akin to how default cache works currently, but you
>         would get to
>         > define your default template configuration at runtime. This
>         sounded like the
>         > best option to me, but the problem is what if someone calls
>         getCache using
>         > the same cache name but a different template. This could get
>         hairy as well.
>         >
>         > Really thinking about the future, disconnecting the cache
>         definition and
>         > retrieval would be the best option, but we can't do that
>         this late in the
>         > game.
>         >
>         > What do you guys think?
>         >
>         >  - Will
>         >
>         > _______________________________________________
>         > infinispan-dev mailing list
>         > [hidden email]
>         <mailto:[hidden email]>
>         > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>         _______________________________________________
>         infinispan-dev mailing list
>         [hidden email]
>         <mailto:[hidden email]>
>         https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Calling getCache with a template and defined configuration

Thomas SEGISMONT
In reply to this post by William Burns-3
Hi

2017-02-28 22:51 GMT+01:00 William Burns <[hidden email]>:
So while I was trying to work on this, I have to admit I am even more torn in regards to what to do.  Looking at [1]  it looks like the template should only be applied if the cache configuration is not currently defined.  Unfortunately it doesn't work this way and always applies this template to any existing configuration. So I am thinking an alternative is to instead make it work as the documentation states, only using the template if the cache is not currently defined.  This seems more logical to me at least.

I guess you started this conversation because of the issue you found in vertx-infinispan :) Then yes, when I used this method the Javadoc made me think that the template would be picked if no cache with the provided name exists.
 

With that change the getCache(String, String) could stay as long as it is documented that a template is only applied if no cache configuration exists.

What do you guys think?


Sounds better to me since it's what the doc suggests.
 

[1] https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/manager/EmbeddedCacheManager.java#L84

On Mon, Feb 27, 2017 at 10:09 AM William Burns <[hidden email]> wrote:
On Mon, Feb 27, 2017 at 9:55 AM Dan Berindei <[hidden email]> wrote:
I would go for option 2.

Do you think a WARN message will be enough? I am a bit weary about this option myself.
 

We already started disconnecting the cache definition and retrieval,
at least `getCache(name)` doesn't define a new cache based on the
default configuration any more. So I don't think it would be too much,
even at this point, to deprecate all the overloads of `getCache` that
can define a new cache and advise users to use `defineConfiguration`
instead.

Hrmm I like the idea of deprecating the overloads :)
 



Cheers
Dan


On Mon, Feb 27, 2017 at 4:31 PM, William Burns <[hidden email]> wrote:
> When working on another project using Infinispan the code being used was a
> bit interesting and I don't think our template configuration handling was
> expecting it do so in such a way.
>
> Essentially the code defined a template for a distributed cache as well as
> some named caches.  Then whenever a cache is retrieved it would pass the
> given name and always the distributed cache template.  Unfortunately with
> the way templates work they essentially redefine a cache first so the actual
> cache configuration was wiped out.  In this example I was able to get the
> code to change to using a default cache instead, which is the behavior that
> is needed.
>
> The issue though at hand is whether we should allow a user to call getCache
> in such a way. My initial thought is to have it throw some sort of
> configuration exception when this is invoked. But there are some possible
> options.
>
> 1. Throw a configuration exception not allowing a user to use a template
> with an already defined cache. This has a slight disconnect between
> configuration and runtime, since if a user adds a new definition it could
> cause runtime issues.
> 2. Log an error/warning message when this occurs. Is this enough though?
> Still could have runtime issues that are possibly undetected.
> 3. Merge the configurations together applying the template first.  This
> would be akin to how default cache works currently, but you would get to
> define your default template configuration at runtime. This sounded like the
> best option to me, but the problem is what if someone calls getCache using
> the same cache name but a different template. This could get hairy as well.
>
> Really thinking about the future, disconnecting the cache definition and
> retrieval would be the best option, but we can't do that this late in the
> game.
>
> What do you guys think?
>
>  - Will
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Calling getCache with a template and defined configuration

Dan Berindei
In reply to this post by Radim Vansa
On Wed, Mar 1, 2017 at 10:18 AM, Radim Vansa <[hidden email]> wrote:

> I still think that if the cache is already defined, defineConfiguration
> should throw an exception. This javadoc was written 7 years ago [1],
> maybe with a different intention.
> Strange and complex combinations don't help. We have made a clear
> separation between templates and cache configurations; you should not
> use regular cache configuration as a template for programmatically
> defined cache anymore, and if you really want to, there are means to
> that (load, undefine, define).
>
> Btw., the javadoc is out of date, too, since it mentions default cache
> which has been removed recently.
>

That defineConfiguration javadoc is just weird, it says what the
Configuration returned by the method will be but it doesn't say what
the configuration associated with that cache name in the cache manager
will be...

I agree with throwing an exception in defineConfiguration(...) when
that cache is already defined. I would not throw an exception from
getCache(cache, configurationName) when the cache is already defined,
I'd just ignore the new configuration (as we already ignore it when
the cache is runninng) and maybe log a warning telling people to use
defineConfiguration(cacheName, configurationName, new
ConfigurationBuilder().build()) + getCache(cacheName).

Cheers
Dan


> R.
>
> [1]
> https://github.com/infinispan/infinispan/commit/73d99d37ebfb8af6b64df6a7579a2448deacbde7#diff-e2b618b97769a45ec42eb5910a8c2119R62
>
> On 02/28/2017 10:51 PM, William Burns wrote:
>> So while I was trying to work on this, I have to admit I am even more
>> torn in regards to what to do.  Looking at [1] it looks like the
>> template should only be applied if the cache configuration is not
>> currently defined.  Unfortunately it doesn't work this way and always
>> applies this template to any existing configuration. So I am thinking
>> an alternative is to instead make it work as the documentation states,
>> only using the template if the cache is not currently defined. This
>> seems more logical to me at least.
>>
>> With that change the getCache(String, String) could stay as long as it
>> is documented that a template is only applied if no cache
>> configuration exists.
>>
>> What do you guys think?
>>
>> [1]
>> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/manager/EmbeddedCacheManager.java#L84
>>
>>
>> On Mon, Feb 27, 2017 at 10:09 AM William Burns <[hidden email]
>> <mailto:[hidden email]>> wrote:
>>
>>     On Mon, Feb 27, 2017 at 9:55 AM Dan Berindei
>>     <[hidden email] <mailto:[hidden email]>> wrote:
>>
>>         I would go for option 2.
>>
>>
>>     Do you think a WARN message will be enough? I am a bit weary about
>>     this option myself.
>>
>>
>>         We already started disconnecting the cache definition and
>>         retrieval,
>>         at least `getCache(name)` doesn't define a new cache based on the
>>         default configuration any more. So I don't think it would be
>>         too much,
>>         even at this point, to deprecate all the overloads of
>>         `getCache` that
>>         can define a new cache and advise users to use
>>         `defineConfiguration`
>>         instead.
>>
>>
>>     Hrmm I like the idea of deprecating the overloads :)
>>
>>
>>
>>
>>         Cheers
>>         Dan
>>
>>
>>         On Mon, Feb 27, 2017 at 4:31 PM, William Burns
>>         <[hidden email] <mailto:[hidden email]>> wrote:
>>         > When working on another project using Infinispan the code
>>         being used was a
>>         > bit interesting and I don't think our template configuration
>>         handling was
>>         > expecting it do so in such a way.
>>         >
>>         > Essentially the code defined a template for a distributed
>>         cache as well as
>>         > some named caches.  Then whenever a cache is retrieved it
>>         would pass the
>>         > given name and always the distributed cache template.
>>         Unfortunately with
>>         > the way templates work they essentially redefine a cache
>>         first so the actual
>>         > cache configuration was wiped out.  In this example I was
>>         able to get the
>>         > code to change to using a default cache instead, which is
>>         the behavior that
>>         > is needed.
>>         >
>>         > The issue though at hand is whether we should allow a user
>>         to call getCache
>>         > in such a way. My initial thought is to have it throw some
>>         sort of
>>         > configuration exception when this is invoked. But there are
>>         some possible
>>         > options.
>>         >
>>         > 1. Throw a configuration exception not allowing a user to
>>         use a template
>>         > with an already defined cache. This has a slight disconnect
>>         between
>>         > configuration and runtime, since if a user adds a new
>>         definition it could
>>         > cause runtime issues.
>>         > 2. Log an error/warning message when this occurs. Is this
>>         enough though?
>>         > Still could have runtime issues that are possibly undetected.
>>         > 3. Merge the configurations together applying the template
>>         first.  This
>>         > would be akin to how default cache works currently, but you
>>         would get to
>>         > define your default template configuration at runtime. This
>>         sounded like the
>>         > best option to me, but the problem is what if someone calls
>>         getCache using
>>         > the same cache name but a different template. This could get
>>         hairy as well.
>>         >
>>         > Really thinking about the future, disconnecting the cache
>>         definition and
>>         > retrieval would be the best option, but we can't do that
>>         this late in the
>>         > game.
>>         >
>>         > What do you guys think?
>>         >
>>         >  - Will
>>         >
>>         > _______________________________________________
>>         > infinispan-dev mailing list
>>         > [hidden email]
>>         <mailto:[hidden email]>
>>         > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>         _______________________________________________
>>         infinispan-dev mailing list
>>         [hidden email]
>>         <mailto:[hidden email]>
>>         https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
>
> --
> Radim Vansa <[hidden email]>
> JBoss Performance Team
>
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Calling getCache with a template and defined configuration

Tristan Tarrant-2
On 01/03/17 13:01, Dan Berindei wrote:
> On Wed, Mar 1, 2017 at 10:18 AM, Radim Vansa <[hidden email]> wrote:
>> I still think that if the cache is already defined, defineConfiguration
>> should throw an exception. This javadoc was written 7 years ago [1],

> I agree with throwing an exception in defineConfiguration(...) when
> that cache is already defined.

+1

> getCache(cache, configurationName) when the cache is already defined,
> I'd just ignore the new configuration (as we already ignore it when
> the cache is runninng) and maybe log a warning telling people to use
> defineConfiguration(cacheName, configurationName, new
> ConfigurationBuilder().build()) + getCache(cacheName).

+1

Tristan

>> R.
>>
>> [1]
>> https://github.com/infinispan/infinispan/commit/73d99d37ebfb8af6b64df6a7579a2448deacbde7#diff-e2b618b97769a45ec42eb5910a8c2119R62
>>
>> On 02/28/2017 10:51 PM, William Burns wrote:
>>> So while I was trying to work on this, I have to admit I am even more
>>> torn in regards to what to do.  Looking at [1] it looks like the
>>> template should only be applied if the cache configuration is not
>>> currently defined.  Unfortunately it doesn't work this way and always
>>> applies this template to any existing configuration. So I am thinking
>>> an alternative is to instead make it work as the documentation states,
>>> only using the template if the cache is not currently defined. This
>>> seems more logical to me at least.
>>>
>>> With that change the getCache(String, String) could stay as long as it
>>> is documented that a template is only applied if no cache
>>> configuration exists.
>>>
>>> What do you guys think?
>>>
>>> [1]
>>> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/manager/EmbeddedCacheManager.java#L84
>>>
>>>
>>> On Mon, Feb 27, 2017 at 10:09 AM William Burns <[hidden email]
>>> <mailto:[hidden email]>> wrote:
>>>
>>>      On Mon, Feb 27, 2017 at 9:55 AM Dan Berindei
>>>      <[hidden email] <mailto:[hidden email]>> wrote:
>>>
>>>          I would go for option 2.
>>>
>>>
>>>      Do you think a WARN message will be enough? I am a bit weary about
>>>      this option myself.
>>>
>>>
>>>          We already started disconnecting the cache definition and
>>>          retrieval,
>>>          at least `getCache(name)` doesn't define a new cache based on the
>>>          default configuration any more. So I don't think it would be
>>>          too much,
>>>          even at this point, to deprecate all the overloads of
>>>          `getCache` that
>>>          can define a new cache and advise users to use
>>>          `defineConfiguration`
>>>          instead.
>>>
>>>
>>>      Hrmm I like the idea of deprecating the overloads :)
>>>
>>>
>>>
>>>
>>>          Cheers
>>>          Dan
>>>
>>>
>>>          On Mon, Feb 27, 2017 at 4:31 PM, William Burns
>>>          <[hidden email] <mailto:[hidden email]>> wrote:
>>>          > When working on another project using Infinispan the code
>>>          being used was a
>>>          > bit interesting and I don't think our template configuration
>>>          handling was
>>>          > expecting it do so in such a way.
>>>          >
>>>          > Essentially the code defined a template for a distributed
>>>          cache as well as
>>>          > some named caches.  Then whenever a cache is retrieved it
>>>          would pass the
>>>          > given name and always the distributed cache template.
>>>          Unfortunately with
>>>          > the way templates work they essentially redefine a cache
>>>          first so the actual
>>>          > cache configuration was wiped out.  In this example I was
>>>          able to get the
>>>          > code to change to using a default cache instead, which is
>>>          the behavior that
>>>          > is needed.
>>>          >
>>>          > The issue though at hand is whether we should allow a user
>>>          to call getCache
>>>          > in such a way. My initial thought is to have it throw some
>>>          sort of
>>>          > configuration exception when this is invoked. But there are
>>>          some possible
>>>          > options.
>>>          >
>>>          > 1. Throw a configuration exception not allowing a user to
>>>          use a template
>>>          > with an already defined cache. This has a slight disconnect
>>>          between
>>>          > configuration and runtime, since if a user adds a new
>>>          definition it could
>>>          > cause runtime issues.
>>>          > 2. Log an error/warning message when this occurs. Is this
>>>          enough though?
>>>          > Still could have runtime issues that are possibly undetected.
>>>          > 3. Merge the configurations together applying the template
>>>          first.  This
>>>          > would be akin to how default cache works currently, but you
>>>          would get to
>>>          > define your default template configuration at runtime. This
>>>          sounded like the
>>>          > best option to me, but the problem is what if someone calls
>>>          getCache using
>>>          > the same cache name but a different template. This could get
>>>          hairy as well.
>>>          >
>>>          > Really thinking about the future, disconnecting the cache
>>>          definition and
>>>          > retrieval would be the best option, but we can't do that
>>>          this late in the
>>>          > game.
>>>          >
>>>          > What do you guys think?
>>>          >
>>>          >  - Will
>>>          >
>>>          > _______________________________________________
>>>          > infinispan-dev mailing list
>>>          > [hidden email]
>>>          <mailto:[hidden email]>
>>>          > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>          _______________________________________________
>>>          infinispan-dev mailing list
>>>          [hidden email]
>>>          <mailto:[hidden email]>
>>>          https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> --
>> Radim Vansa <[hidden email]>
>> JBoss Performance Team
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Calling getCache with a template and defined configuration

William Burns-3
Alright seems fine to me.

On Wed, Mar 1, 2017, 9:27 AM Tristan Tarrant <[hidden email]> wrote:
On 01/03/17 13:01, Dan Berindei wrote:
> On Wed, Mar 1, 2017 at 10:18 AM, Radim Vansa <[hidden email]> wrote:
>> I still think that if the cache is already defined, defineConfiguration
>> should throw an exception. This javadoc was written 7 years ago [1],

> I agree with throwing an exception in defineConfiguration(...) when
> that cache is already defined.

+1

I get a lot of tests to change and remove now 😁


> getCache(cache, configurationName) when the cache is already defined,
> I'd just ignore the new configuration (as we already ignore it when
> the cache is runninng) and maybe log a warning telling people to use
> defineConfiguration(cacheName, configurationName, new
> ConfigurationBuilder().build()) + getCache(cacheName).

+1

Tristan

>> R.
>>
>> [1]
>> https://github.com/infinispan/infinispan/commit/73d99d37ebfb8af6b64df6a7579a2448deacbde7#diff-e2b618b97769a45ec42eb5910a8c2119R62
>>
>> On 02/28/2017 10:51 PM, William Burns wrote:
>>> So while I was trying to work on this, I have to admit I am even more
>>> torn in regards to what to do.  Looking at [1] it looks like the
>>> template should only be applied if the cache configuration is not
>>> currently defined.  Unfortunately it doesn't work this way and always
>>> applies this template to any existing configuration. So I am thinking
>>> an alternative is to instead make it work as the documentation states,
>>> only using the template if the cache is not currently defined. This
>>> seems more logical to me at least.
>>>
>>> With that change the getCache(String, String) could stay as long as it
>>> is documented that a template is only applied if no cache
>>> configuration exists.
>>>
>>> What do you guys think?
>>>
>>> [1]
>>> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/manager/EmbeddedCacheManager.java#L84
>>>
>>>
>>> On Mon, Feb 27, 2017 at 10:09 AM William Burns <[hidden email]
>>> <mailto:[hidden email]>> wrote:
>>>
>>>      On Mon, Feb 27, 2017 at 9:55 AM Dan Berindei
>>>      <[hidden email] <mailto:[hidden email]>> wrote:
>>>
>>>          I would go for option 2.
>>>
>>>
>>>      Do you think a WARN message will be enough? I am a bit weary about
>>>      this option myself.
>>>
>>>
>>>          We already started disconnecting the cache definition and
>>>          retrieval,
>>>          at least `getCache(name)` doesn't define a new cache based on the
>>>          default configuration any more. So I don't think it would be
>>>          too much,
>>>          even at this point, to deprecate all the overloads of
>>>          `getCache` that
>>>          can define a new cache and advise users to use
>>>          `defineConfiguration`
>>>          instead.
>>>
>>>
>>>      Hrmm I like the idea of deprecating the overloads :)
>>>
>>>
>>>
>>>
>>>          Cheers
>>>          Dan
>>>
>>>
>>>          On Mon, Feb 27, 2017 at 4:31 PM, William Burns
>>>          <[hidden email] <mailto:[hidden email]>> wrote:
>>>          > When working on another project using Infinispan the code
>>>          being used was a
>>>          > bit interesting and I don't think our template configuration
>>>          handling was
>>>          > expecting it do so in such a way.
>>>          >
>>>          > Essentially the code defined a template for a distributed
>>>          cache as well as
>>>          > some named caches.  Then whenever a cache is retrieved it
>>>          would pass the
>>>          > given name and always the distributed cache template.
>>>          Unfortunately with
>>>          > the way templates work they essentially redefine a cache
>>>          first so the actual
>>>          > cache configuration was wiped out.  In this example I was
>>>          able to get the
>>>          > code to change to using a default cache instead, which is
>>>          the behavior that
>>>          > is needed.
>>>          >
>>>          > The issue though at hand is whether we should allow a user
>>>          to call getCache
>>>          > in such a way. My initial thought is to have it throw some
>>>          sort of
>>>          > configuration exception when this is invoked. But there are
>>>          some possible
>>>          > options.
>>>          >
>>>          > 1. Throw a configuration exception not allowing a user to
>>>          use a template
>>>          > with an already defined cache. This has a slight disconnect
>>>          between
>>>          > configuration and runtime, since if a user adds a new
>>>          definition it could
>>>          > cause runtime issues.
>>>          > 2. Log an error/warning message when this occurs. Is this
>>>          enough though?
>>>          > Still could have runtime issues that are possibly undetected.
>>>          > 3. Merge the configurations together applying the template
>>>          first.  This
>>>          > would be akin to how default cache works currently, but you
>>>          would get to
>>>          > define your default template configuration at runtime. This
>>>          sounded like the
>>>          > best option to me, but the problem is what if someone calls
>>>          getCache using
>>>          > the same cache name but a different template. This could get
>>>          hairy as well.
>>>          >
>>>          > Really thinking about the future, disconnecting the cache
>>>          definition and
>>>          > retrieval would be the best option, but we can't do that
>>>          this late in the
>>>          > game.
>>>          >
>>>          > What do you guys think?
>>>          >
>>>          >  - Will
>>>          >
>>>          > _______________________________________________
>>>          > infinispan-dev mailing list
>>>          > [hidden email]
>>>          <mailto:[hidden email]>
>>>          > https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>          _______________________________________________
>>>          infinispan-dev mailing list
>>>          [hidden email]
>>>          <mailto:[hidden email]>
>>>          https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>
>>
>> --
>> Radim Vansa <[hidden email]>
>> JBoss Performance Team
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> _______________________________________________
> infinispan-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Reply | Threaded
Open this post in threaded view
|

Re: [infinispan-dev] Calling getCache with a template and defined configuration

Galder Zamarreño
In reply to this post by Dan Berindei

--
Galder Zamarreño
Infinispan, Red Hat

On 1 Mar 2017, at 07:01, Dan Berindei <[hidden email]> wrote:

On Wed, Mar 1, 2017 at 10:18 AM, Radim Vansa <[hidden email]> wrote:
I still think that if the cache is already defined, defineConfiguration
should throw an exception. This javadoc was written 7 years ago [1],
maybe with a different intention.
Strange and complex combinations don't help. We have made a clear
separation between templates and cache configurations; you should not
use regular cache configuration as a template for programmatically
defined cache anymore, and if you really want to, there are means to
that (load, undefine, define).

Btw., the javadoc is out of date, too, since it mentions default cache
which has been removed recently.


That defineConfiguration javadoc is just weird,

^ Most likely my fault! :$ ;)

it says what the
Configuration returned by the method will be but it doesn't say what
the configuration associated with that cache name in the cache manager
will be...

I agree with throwing an exception in defineConfiguration(...) when
that cache is already defined. I would not throw an exception from
getCache(cache, configurationName) when the cache is already defined,
I'd just ignore the new configuration (as we already ignore it when
the cache is runninng) and maybe log a warning telling people to use
defineConfiguration(cacheName, configurationName, new
ConfigurationBuilder().build()) + getCache(cacheName).

Cheers
Dan


R.

[1]
https://github.com/infinispan/infinispan/commit/73d99d37ebfb8af6b64df6a7579a2448deacbde7#diff-e2b618b97769a45ec42eb5910a8c2119R62

On 02/28/2017 10:51 PM, William Burns wrote:
So while I was trying to work on this, I have to admit I am even more
torn in regards to what to do.  Looking at [1] it looks like the
template should only be applied if the cache configuration is not
currently defined.  Unfortunately it doesn't work this way and always
applies this template to any existing configuration. So I am thinking
an alternative is to instead make it work as the documentation states,
only using the template if the cache is not currently defined. This
seems more logical to me at least.

With that change the getCache(String, String) could stay as long as it
is documented that a template is only applied if no cache
configuration exists.

What do you guys think?

[1]
https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/manager/EmbeddedCacheManager.java#L84


On Mon, Feb 27, 2017 at 10:09 AM William Burns <[hidden email]
<mailto:[hidden email]>> wrote:

  On Mon, Feb 27, 2017 at 9:55 AM Dan Berindei
  <[hidden email] <mailto:[hidden email]>> wrote:

      I would go for option 2.


  Do you think a WARN message will be enough? I am a bit weary about
  this option myself.


      We already started disconnecting the cache definition and
      retrieval,
      at least `getCache(name)` doesn't define a new cache based on the
      default configuration any more. So I don't think it would be
      too much,
      even at this point, to deprecate all the overloads of
      `getCache` that
      can define a new cache and advise users to use
      `defineConfiguration`
      instead.


  Hrmm I like the idea of deprecating the overloads :)




      Cheers
      Dan


      On Mon, Feb 27, 2017 at 4:31 PM, William Burns
      <[hidden email] <mailto:[hidden email]>> wrote:
When working on another project using Infinispan the code
      being used was a
bit interesting and I don't think our template configuration
      handling was
expecting it do so in such a way.

Essentially the code defined a template for a distributed
      cache as well as
some named caches.  Then whenever a cache is retrieved it
      would pass the
given name and always the distributed cache template.
      Unfortunately with
the way templates work they essentially redefine a cache
      first so the actual
cache configuration was wiped out.  In this example I was
      able to get the
code to change to using a default cache instead, which is
      the behavior that
is needed.

The issue though at hand is whether we should allow a user
      to call getCache
in such a way. My initial thought is to have it throw some
      sort of
configuration exception when this is invoked. But there are
      some possible
options.

1. Throw a configuration exception not allowing a user to
      use a template
with an already defined cache. This has a slight disconnect
      between
configuration and runtime, since if a user adds a new
      definition it could
cause runtime issues.
2. Log an error/warning message when this occurs. Is this
      enough though?
Still could have runtime issues that are possibly undetected.
3. Merge the configurations together applying the template
      first.  This
would be akin to how default cache works currently, but you
      would get to
define your default template configuration at runtime. This
      sounded like the
best option to me, but the problem is what if someone calls
      getCache using
the same cache name but a different template. This could get
      hairy as well.

Really thinking about the future, disconnecting the cache
      definition and
retrieval would be the best option, but we can't do that
      this late in the
game.

What do you guys think?

- Will

_______________________________________________
infinispan-dev mailing list
[hidden email]
      <mailto:[hidden email]>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
      _______________________________________________
      infinispan-dev mailing list
      [hidden email]
      <mailto:[hidden email]>
      https://lists.jboss.org/mailman/listinfo/infinispan-dev



_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


--
Radim Vansa <[hidden email]>
JBoss Performance Team

_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev


_______________________________________________
infinispan-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/infinispan-dev